On Wed, 2010-05-12 at 08:02 +0200, Steffen Sledz wrote: > 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.
It sounds like we have, perhaps, been talking at slight cross purposes. It is true that you can build glibc against a different version of linux-libc-headers than the version of the kernel that will be used at runtime. So long as the runtime kernel version is newer than the minimum kernel version that glibc was configured for (either via --enable-kernel=XXX, or via an architecture-specific static definition) then everything should still work fine, and glibc will use internal fallbacks if it discovers that certain system calls are not available at runtime. Similarly, glibc will make some efforts to provide a backwards compatible emulation for user-visible interfaces which might not be available in all kernel versions. However, what it doesn't attempt to do is provide a completely virtualised ABI which would insulate the application entirely from the details of the running kernel. There are some kernel features which simply aren't feasible to emulate in user space. In the specific case of epoll_create1() and inotify_init1(), it would be reasonable for glibc to do something similar to the way that, say, mmap64() is handled. That is, if the kernel doesn't have epoll_create1() but does have epoll_create(), and the behaviour that the user has requested is something that epoll_create() can do (i.e. none of the flag bits are set) then use epoll_create(). But if the user has asked for EPOLL_CLOEXEC then epoll_create() is not a suitable replacement and you are going to get ENOSYS: it's then up to the application to take some suitable recovery action. p. _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel