[oe] Kernel Headers Quality Issue

[Tom Rini]

On Tue, 2010-05-11 at 09:42 +0200, Steffen Sledz wrote:
> 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).

Yes, my fault, sorry, it's indeed --enable-kernel=.

> 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). :(

All of this information is _not_ coming from glibc claiming that a
syscall exists, but it's coming from the linux-libc-headers having them
(which is why if you downgrade, they build and run as you expect them
to).  Then there's the problem, as others have stated, that it's up to
userland to gracefully handle if a syscall isn't really available.  You
noted before that glib-2.0 falls back to using something very
inefficient, rather than a less efficient syscall that does exist, yes?

-- 
Tom Rini <tom_rini at mentor.com>
Mentor Graphics Corporation