[oe] Kernel Headers Quality Issue

[Tom Rini]

On Wed, 2010-05-12 at 08:02 +0200, Steffen Sledz wrote:
> 11.05.2010 16:27, Tom Rini wrote:
> > 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.
> 
> <grrrr> Now i'm totally confused. Here's a short summary as i understand
> this thread (may be i misunderstand something).

Well, here is my understanding.

> My initial understanding was:
> 
> linux-libc-headers match to kernel version

In an ideal world, yes.  Because the various <asm/...> and <linux/...>
files that are exported for use do indeed get new features added over
time. And...

> -> autotools report existing syscalls

All the autotools stuff does is:
(a) If we provide in openembedded/site/... a variable to set a check to
a value, use it
(b) Try and compile a test program to check for availability (since it
can't then run the program for a cross build).

> -> apps can use them
> -> fine

Right.

> Then Koen wrote: no chance to change linux-libc-headers for angstrom

Right.  Angstrom has a publicly usable download feed and there's no way
to tell if a file there was built vs .31 (and may have syscalls
introduced around then) or .25 (and won't).  That's a very bad situation
for Angstrom.

> Graeme and Phil wrote something like no problem, "glibc was supposed
> to gracefully fall back on missing syscalls". What i understand as
> 
> linux-libc-headers may be newer than kernel version
> -> 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.

Yes.  And just now, Phil has provided an example of handling a syscall.

> Then you wrote that *every app* itself is responsible to handle syscalls
> which are reported by autotools (linux-libc-headers) as *available* but
> are *not available* ? I can't believe that. This sounds absurd for me.

This is how I read what Phil and possibly someone else too were saying,
and based on your observation that glib for example will fall back at
run time.

> So please enlighten my confusions.
> 
> Regards,
> Steffen
> 
> PS:
> 
> > You noted before that glib-2.0 falls back to using something very
> > inefficient, rather than a less efficient syscall that does exist, yes?
> 
> What glib does is checking the availability (by using autotools) of inotify (in various levels), fam, or plain polling.

So you did not see it change behavior at run time?  That's how I had
read your email before.

> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel


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