Re: Kernel Headers Quality Issue

[Steffen Sledz <sledz@dresearch.de>]

Am 10.05.2010 21:14, Tom Rini wrote:
> Looking at it again and based on what Khem said (and re-reading your
> failures), the problem is not with glibc, but with other programs (glib,
> udev are both mentioned specifically) and these programs specifically
> not failing gracefully.  For example, it's quoted over in:
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-May/019626.html
> that glib falls way back.  I think Phil was wrong here and without
> checking the code, I imagine glib is trying fancy newer syscall,
> failing, and then falling far back, rather than to just inotify_init as
> you expected.  So the bug here is with glib.
> 
> As for the udev issue, I do not know how they will react to making the
> udev version be soft-assign as that too may raise issues.  And iirc,
> udev is or at least can be more tied to min kernel versions.

No, it seems not to be a problem of glib, rsyslog, or udev.

As i see in the build logs glibc is build using --enable-kernel=2.6.16 (i do not know any --with-kernel option).

After running autotools config.h of e.g. glib-2.0 contains

 /* Define to 1 if you have the `inotify_init1' function. */
 #define HAVE_INOTIFY_INIT1 1

So the glib-2.0 is allowed to use inotify_init1. But this is only available for kernel version >= 2.6.27.

Same behaviour for epoll_create1 in e.g. rsyslog

 /* Define to 1 if you have the `epoll_create' function. */
 #define HAVE_EPOLL_CREATE 1

 /* Define to 1 if you have the `epoll_create1' function. */
 #define HAVE_EPOLL_CREATE1 1

Conclusion: glibc reports functions "available" which are not available for our kernel 2.6.24 (and not "emulated" inside glibc). :(

Regards, Steffen