[oe] Kernel Headers Quality Issue

[Mark Brown]

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.