| Message ID | b5e234a305d5baa9c177d78baed4754f2093ffbb.1309198794.git.jan.kiszka@web.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Jun 27, 2011 at 08:19:47PM +0200, Jan Kiszka wrote: > From: Jan Kiszka <jan.kiszka@siemens.com> > > No longer used. > > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> I think it's actually handy to build on old systems which have a recent enough kernel but not the header. Does it hurt much to keep it around? > --- > compat/sys/eventfd.h | 13 ------------- > 1 files changed, 0 insertions(+), 13 deletions(-) > delete mode 100644 compat/sys/eventfd.h > > diff --git a/compat/sys/eventfd.h b/compat/sys/eventfd.h > deleted file mode 100644 > index f55d96a..0000000 > --- a/compat/sys/eventfd.h > +++ /dev/null > @@ -1,13 +0,0 @@ > -#ifndef _COMPAT_SYS_EVENTFD > -#define _COMPAT_SYS_EVENTFD > - > -#include <unistd.h> > -#include <syscall.h> > - > - > -static inline int eventfd (int count, int flags) > -{ > - return syscall(SYS_eventfd, count, flags); > -} > - > -#endif > -- > 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2011-06-28 13:09, Michael S. Tsirkin wrote: > On Mon, Jun 27, 2011 at 08:19:47PM +0200, Jan Kiszka wrote: >> From: Jan Kiszka <jan.kiszka@siemens.com> >> >> No longer used. >> >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > > I think it's actually handy to build on old systems which have > a recent enough kernel but not the header. > Does it hurt much to keep it around? Unless I missed something, it's not part of any include search path. So how can it help? But if you think such a header is useful, then get it upstream. Jan
On Tue, Jun 28, 2011 at 01:11:20PM +0200, Jan Kiszka wrote: > On 2011-06-28 13:09, Michael S. Tsirkin wrote: > > On Mon, Jun 27, 2011 at 08:19:47PM +0200, Jan Kiszka wrote: > >> From: Jan Kiszka <jan.kiszka@siemens.com> > >> > >> No longer used. > >> > >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > > > > I think it's actually handy to build on old systems which have > > a recent enough kernel but not the header. > > Does it hurt much to keep it around? > > Unless I missed something, it's not part of any include search path. So > how can it help? > We used to have compat last on search path. Is that no longer so? I can try and dig up an old host that has this configuration. > But if you think such a header is useful, then get it upstream. > > Jan It's not upstream because we didn't used to have system headers upstream. Now that we do it makes sense I think ...
On 2011-06-28 14:07, Michael S. Tsirkin wrote: > On Tue, Jun 28, 2011 at 01:11:20PM +0200, Jan Kiszka wrote: >> On 2011-06-28 13:09, Michael S. Tsirkin wrote: >>> On Mon, Jun 27, 2011 at 08:19:47PM +0200, Jan Kiszka wrote: >>>> From: Jan Kiszka <jan.kiszka@siemens.com> >>>> >>>> No longer used. >>>> >>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >>> >>> I think it's actually handy to build on old systems which have >>> a recent enough kernel but not the header. >>> Does it hurt much to keep it around? >> >> Unless I missed something, it's not part of any include search path. So >> how can it help? >> > > We used to have compat last on search path. Is that no longer so? I did a grep for "compat" and found nothing suspicious in configure or some makefile. So this file looked like dead bits to me. Jan
On Tue, Jun 28, 2011 at 02:11:23PM +0200, Jan Kiszka wrote: > On 2011-06-28 14:07, Michael S. Tsirkin wrote: > > On Tue, Jun 28, 2011 at 01:11:20PM +0200, Jan Kiszka wrote: > >> On 2011-06-28 13:09, Michael S. Tsirkin wrote: > >>> On Mon, Jun 27, 2011 at 08:19:47PM +0200, Jan Kiszka wrote: > >>>> From: Jan Kiszka <jan.kiszka@siemens.com> > >>>> > >>>> No longer used. > >>>> > >>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > >>> > >>> I think it's actually handy to build on old systems which have > >>> a recent enough kernel but not the header. > >>> Does it hurt much to keep it around? > >> > >> Unless I missed something, it's not part of any include search path. So > >> how can it help? > >> > > > > We used to have compat last on search path. Is that no longer so? > > I did a grep for "compat" and found nothing suspicious in configure or > some makefile. So this file looked like dead bits to me. > > Jan > kvm_cflags="$kvm_cflags -idirafter $source_path/compat" -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2011-06-28 14:17, Michael S. Tsirkin wrote: > On Tue, Jun 28, 2011 at 02:11:23PM +0200, Jan Kiszka wrote: >> On 2011-06-28 14:07, Michael S. Tsirkin wrote: >>> On Tue, Jun 28, 2011 at 01:11:20PM +0200, Jan Kiszka wrote: >>>> On 2011-06-28 13:09, Michael S. Tsirkin wrote: >>>>> On Mon, Jun 27, 2011 at 08:19:47PM +0200, Jan Kiszka wrote: >>>>>> From: Jan Kiszka <jan.kiszka@siemens.com> >>>>>> >>>>>> No longer used. >>>>>> >>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >>>>> >>>>> I think it's actually handy to build on old systems which have >>>>> a recent enough kernel but not the header. >>>>> Does it hurt much to keep it around? >>>> >>>> Unless I missed something, it's not part of any include search path. So >>>> how can it help? >>>> >>> >>> We used to have compat last on search path. Is that no longer so? >> >> I did a grep for "compat" and found nothing suspicious in configure or >> some makefile. So this file looked like dead bits to me. >> >> Jan >> > > kvm_cflags="$kvm_cflags -idirafter $source_path/compat" > I see. That was dropped with the recent upstream merge (c13a890960). Please check what setup benefited from it, and then discuss if and how to reintroduce it via upstream. Jan
Am 28.06.2011 13:09, schrieb Michael S. Tsirkin: > On Mon, Jun 27, 2011 at 08:19:47PM +0200, Jan Kiszka wrote: >> From: Jan Kiszka<jan.kiszka@siemens.com> >> >> No longer used. >> >> Signed-off-by: Jan Kiszka<jan.kiszka@siemens.com> > > I think it's actually handy to build on old systems which have > a recent enough kernel but not the header. Yep, I'm running recent qemu-kvm and kernels on CentOS 5.6. The current eventfd.h was handy in the beginning, but some day I had big troubles with crashing qemu-kvm. It turned out that I had to switch from eventfd to eventfd2. IIRC the old eventfd doesn't care about the flags. My version of eventfd.h is attached. Bernhard >> --- >> compat/sys/eventfd.h | 13 ------------- >> 1 files changed, 0 insertions(+), 13 deletions(-) >> delete mode 100644 compat/sys/eventfd.h >> >> diff --git a/compat/sys/eventfd.h b/compat/sys/eventfd.h >> deleted file mode 100644 >> index f55d96a..0000000 >> --- a/compat/sys/eventfd.h >> +++ /dev/null >> @@ -1,13 +0,0 @@ >> -#ifndef _COMPAT_SYS_EVENTFD >> -#define _COMPAT_SYS_EVENTFD >> - >> -#include<unistd.h> >> -#include<syscall.h> >> - >> - >> -static inline int eventfd (int count, int flags) >> -{ >> - return syscall(SYS_eventfd, count, flags); >> -} >> - >> -#endif >> -- >> 1.7.1 > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
On Sun, Jul 03, 2011 at 12:54:06PM +0300, Michael S. Tsirkin wrote: > On Sun, Jul 03, 2011 at 11:46:51AM +0200, Bernhard Held wrote: > > #ifndef _COMPAT_SYS_EVENTFD > > #define _COMPAT_SYS_EVENTFD > > > > #include <unistd.h> > > #include <syscall.h> > > > > /* Flags for signalfd. */ > > enum > > { > > EFD_SEMAPHORE = 1, > > #define EFD_SEMAPHORE EFD_SEMAPHORE > > EFD_CLOEXEC = 02000000, > > #define EFD_CLOEXEC EFD_CLOEXEC > > EFD_NONBLOCK = 04000 > > #define EFD_NONBLOCK EFD_NONBLOCK > > }; > > > > #ifndef __NR_eventfd2 > > #if defined(__x86_64__) > > #define __NR_eventfd2 290 > > #elif defined(__i386__) > > #define __NR_eventfd2 328 > > #else > > #error Cannot detect your architecture! > > #endif > > #endif > > Can't we use SYS_eventfd2 instead? Looks like we can't, but __NR_eventfd2 does seem to exit? > > static inline int eventfd (int count, int flags) > > { > > return syscall(__NR_eventfd2, count, flags); > > } > > > > #endif > > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jul 04, 2011 at 02:13:36PM +0200, Bernhard Held wrote: > Am 04.07.2011 12:37, schrieb Michael S. Tsirkin: > >On Sun, Jul 03, 2011 at 08:31:11PM +0200, Bernhard Held wrote: > >>SYS_eventfd2 is not defined on systems with old glibc. These numbers > >>are working for me, for 32 and 64 bit linux. What means > >>"__NR_eventfd2 does seem to exit"? > > > >My system seems to have a definition for the 64 bit > >_NR_eventfd2 in unistd.h. > ># grep __NR_eventfd2 /usr/include/*/*h > >/usr/include/asm-x86_64/unistd.h:#define __NR_eventfd2 290 > >So I think we should use another name to avoid conflicts. > > The definition of __NR_eventfd2 is embraced by > > #ifndef __NR_eventfd2 > ... > #endif > > which effectively avoids conflicts. Not if the system header gets included afterwards. > However the definition of the flags is unconditional, this is indeed buggy. > > Best regards, > Bernhard -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/compat/sys/eventfd.h b/compat/sys/eventfd.h deleted file mode 100644 index f55d96a..0000000 --- a/compat/sys/eventfd.h +++ /dev/null @@ -1,13 +0,0 @@ -#ifndef _COMPAT_SYS_EVENTFD -#define _COMPAT_SYS_EVENTFD - -#include <unistd.h> -#include <syscall.h> - - -static inline int eventfd (int count, int flags) -{ - return syscall(SYS_eventfd, count, flags); -} - -#endif