[oe] linux-libc-headers version (reloaded)

[Frans Meulenbroeks]

2011/2/25 Khem Raj <raj.khem at gmail.com>:
> On Thu, Feb 24, 2011 at 11:40 PM, Steffen Sledz <sledz at dresearch.de> wrote:
>> On 02/24/2011 03:57 PM, Andreas Oberritter wrote:
>>> On 02/24/2011 02:30 PM, Steffen Sledz wrote:
>>>> On 02/18/2011 04:30 PM, Khem Raj wrote:
>>>>> On Fri, Feb 18, 2011 at 1:55 AM, Steffen Sledz <sledz at dresearch.de> wrote:
>>>>>> Am 15.02.2011 15:50, schrieb Steffen Sledz:
>>>>>>> Am 15.02.2011 15:12, schrieb Andreas Oberritter:
>>>>>>>> On 02/15/2011 11:41 AM, Steffen Sledz wrote:
>>>>>>>>> "Kernel headers are backwards compatible, but not forwards compatible.  This
>>>>>>>>> means that a program built against a C library using older kernel headers
>>>>>>>>> should run on a newer kernel (although it may not have access to new
>>>>>>>>> features), but a program built against newer kernel headers may not work on an
>>>>>>>>> older kernel."[2]
>>>>>>>>
>>>>>>>> Isn't this what the variable OLDEST_KERNEL is good for, when compiling
>>>>>>>> glibc?
>>>>>>>
>>>>>>> If i'm right this goes to the --enable-kernel=VERSION configure option of glibc just to optimize the library.
>>>>>>>
>>>>>>> "the configure option --enable-kernel=X.Y.Z allows to strip out compatibility for kernel versions before X.Y.Z."
>>>>>>>
>>>>>>> Imho it is not legitimately to follow that glibc has compatibility code for all kernels greater or equal X.Y.Z.
>>>>>>>
>>>>>>> Another question is the handling in other libc implementations.
>>>>>>>
>>>>>>> And finally there are a lot of programs using userland kernel headers directly.
>>>>>>
>>>>>> Ping!
>>>>>>
>>>>>> If i interpret responses from Tom and Phil right they agree with me (or at least do not disagree). ;-)
>>>>>>
>>>>>> But i miss reactions from the distro maintainers (especially Ångström).
>>>>>>
>>>>>
>>>>> I think we should make sure that linux version chosen for a build is
>>>>> equal or newer than linux-libc-headers for that build. Another option
>>>>> is that linux-libc-headers are driven out
>>>>> of selected virtual/kernel too but this may be a bit clunky since it
>>>>> would mean that
>>>>> every machine will have them different and we share sysroots e.g. two
>>>>> armv5te may use
>>>>> same sysroot
>>>>
>>>> I like to force the discussion/work/decision on this problem because we're one of the mourners (we're forced to use 2.6.24 kernel by out hardware vendor :( ).
>>>>
>>>> I also see the multi-machine problem (the shared sysroot at build time and the feed problem too).
>>>>
>>>> So what options do we (our Ångström) have?
>>>>
>>>> (1) Do not support kernel older than 2.6.31 (which is the current LINUX_LIBC_HEADERS_VERSION).
>>>>
>>>> (2) Set LINUX_LIBC_HEADERS_VERSION to 2.6.16 (which is the current OLDEST_KERNEL).
>>>>
>>>> (3) Support machine specific distro incarnations (incl. special feeds).
>>>>
>>>> May be some more. Option (1) would be really bad for us. I believe (2) would be bad for a lot of users because of a potential loss of functionality.
>>>
>>> I'm still not convinced that requiring older headers is a good way to
>>> go. If applications are using new syscalls directly, they need to handle
>>> ENOSYS. If the applications already contain code to be compatible across
>>> various kernel versions at compile time, then it won't be that hard to
>>> change those applications to detect available interfaces at runtime.
>>
>> At first i believe that practically it is not possible for us to guarantee that all apps do this in the right way. But second i'm not sure if this is the only problem.
>>
>> The kernel docu (what's the primary docu for me) itself says "but a program built against newer kernel headers may not work on an older kernel." (see top of this post).
>>
>> This should be reason enough to avoid newer kernel headers (like all other linux distros do)!
>
> Well one way is to have kernel headers per machine which means you can
> not share target packages anymore since they have to build per machine
> but it would be much integrated solution and we could generate the
> kernel headers from the kernel recipe itself so we are sure that the
> .config of kernel headers match the .config of  kernel itself
> downside is it will defeat the multimachine sharing packages a bit.

Maybe an intermediate is to have kernel headers per kernel recipe.
That still allows multimachine sharing of packages between systems
that use the same arch and kernel recipe.

(and I feel sharing packages between machines with different kernels
is somewhat risky anyway as there might be differences between e.g.
the stock kernel and a kernel pulled from a vendor git or so).

Frans
>
> Second solution is to use the older or equal to oldest kernel of all
> multimachines for kernel headers. the problem Andreas described of
> differen defconfigs will still be there
> but it will work *mostly*
>
>