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 > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel -- Tom Rini <[email protected]> Mentor Graphics Corporation _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
