[oe] Kernel Headers Quality Issue

Mark Brown broonie at sirena.org.uk
Wed May 12 16:53:22 UTC 2010


On Wed, May 12, 2010 at 08:02:53AM +0200, Steffen Sledz wrote:
> 11.05.2010 16:27, Tom Rini wrote:

> -> autotools report availability of some syscalls (e.g. inotify_init1 or epoll_create1)
> -> apps can use them
> -> if called on older kernels glibc will handle this "gracefully"
> -> fine

> But tests showed that glibc did not handle syscalls this way.

It does but...

> Then you wrote that *every app* itself is responsible to handle syscalls
> which are reported by autotools (linux-libc-headers) as *available* but

...what it does not do is emulate syscalls which are being used by
applications directly.  There are a bunch of kernel features which are
used by glibc internally - for those it will just use fallbacks at
runtime.  For things like epoll which are used directly by applications
it's up to the application to decide if it is willing or able to cope on
older systems.  For many kernel features there's no sane possibility of
emulation.

> are *not available* ? I can't believe that. This sounds absurd for me.

glibc is frequently built for systems other than the one it runs on
(obviously, OE is a big example here) so it needs to support building
against a kernel other than the running one, and there's plenty of cases
even with desktop/server systems where it's useful to be able to link
against features which can't be run (eg, user installs old kernel for a
binary driver, or a vendor wants to distribute a binary which can
optionally use newer features but still run on older systems).




More information about the Openembedded-devel mailing list