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

[Sledz, Steffen]

Am 25.02.2011 22:05, schrieb Tom Rini:
> On 02/24/2011 06:30 AM, 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).
> 
> I hate to state the semi-obvious but one of the problems you have now is
> that the distro has said that they want to stay on these more recent
> headers (which are required for building things which do need newer
> headers).  So I think you need to have a (private?) discussion about how
> to do #3 with the least amount of headache.

I really miss a general statement from the Ångström maintainers in this discussion, something like

"We like to support as much machines as possible. So let's try if the machine and/or kernel dependend builds/feeds are a solution."

or

"We like to make a distribution with a guaranteed functionality. For that we need at least linux kernel 2.6.31 (or some other version)." (This should be documented and the try to build/use Ångström with older kernel versions should result in an error/warning.)

or

"It's not possible to fulfill all requirements with one distro. So we split it into Ångström-modern (requires 2.6.31 or newer) and Ångström-nostalgic (for older kernels)."

or something other. With such a statement it would be possible for us (and other users) to make decisions and plans for the future.

Steffen

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz at DResearch.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058