Re: Kernel Headers Quality Issue

[Steffen Sledz <sledz@dresearch.de>]

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

My initial understanding was:

linux-libc-headers match to kernel version
-> autotools report existing syscalls
-> apps can use them
-> fine

Then Koen wrote: no chance to change linux-libc-headers 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.

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.

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.