On Fri, May 14, 2010 at 01:40:24PM +0200, Thilo Fromm wrote: >> Yes. Or, if this is performance critical code, you can cache the result >> (since the kernel is unlikely to suddenly gain support for a syscall >> that it didn't have last time) and go directly to the implementation >> that works.
> This would mean that checking for kernel features (e.g. inotify_init1()) > at compile time via an application's configure.ac is pointless, right? > Because configure will report availability of this interface even though > it won't be there when the application runs. In other words, everything > configure is telling me about kernel features (native kernel thread > availability, inotify, sysfs, ...) might be false anyway. Code like this If you know that you are running on the same system as you are using for the build you *can* write a configure check which actually tries to call the syscall (and will therefore check for -ENOSYS) but obviously this can't be relied upon if someone runs the binary on another system or changes the configuration of the current system. >> Clearly you don't like the idea very much but yes, this is basically how >> backwards compatibility code is done, and it is more or less an >> inescapable consequence of the rather fluid nature of the Linux syscall >> ABI. > I don't like your proposal... but not from an application programmer's > POV, but from the perspective of a system integrator (i.e. a > distribution maintainer). I think just assuming that your proposal is > true for every application I need to integrate would be a mistake and > devastating to a distribution's overall quality. This is something that Linux distributions (and any other system integrator working over multiple OS releases) have always had to deal with. If you're shipping a binary which may run in a different environment to the one it was built in this has always been a possibility. _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
