[oe] Kernel Headers Quality Issue

[Thilo Fromm]

Hello, Tom,

>> this is a somewhat cumulated response - I'd like to address some of the 
>> things mentioned at different points in the discussion in one place. 
>> Please forgive me should I misquote things.
 >>
>> Graeme Gregory in <20100505094242.GF2444 at xora-desktop.xora.org.uk>:
>>
>> [Steffen Sledz]
>>  > > It seem's not to be possible to use DEFAULT_PREFERENCE_hipox in the
>>  > > linux-libc-headers recipes. So what's the right way to handle this?
>>  > > Something like PREFERRED_VERSION_linux-libc-headers_hipox = "2.6.24"
>>  > > in angstrom-2008.1.conf?
>>  >
>> [Graeme Gregory]
>>  > I thought glibc was supposed to gracefully fall back on missing
>>  > syscalls?
>>
>> Glibc is compiled against 2.6.31 headers, which is one of our main 
>> issues here. It only ever *runs* with a 2.6.24 kernel on the target 
>> system, though. So it cannot know about missing syscalls until runtime.
> 
> So, I think some of the confusion here stems from confusion about (and I
> don't know the right answer off-hand) how glibc handles the
> --with-kernel=VERSION stuff.

What is "--with-kernel"? Glibc offers a compile time configuration 
parameter "--enable-kernel", which enables/disables *backwards support* 
library compatibility support for *legacy kernel interfaces*. E.g. if 
you --enable-kernel=2.2.14, you should be able to compile ancient user 
space applications which make use of obsolete kernel 2.2.14 
functionality against the resulting glibc. This makes systems running 
*very recent kernels* provide legacy interfaces of much older kernels 
via the C library. Which is the exact opposite of our situation.

The release notes on glibc 2.2.4, which introduced this option, are 
quite educating (it's Ulrich Drepper writing, so be prepared): 
<http://sourceware.org/ml/libc-announce/2001/msg00000.html> (about 
halfway through the page).

But maybe there is a "--with-kernel" around which does the opposite to 
"--enable-kernel"?

Regards,
Thilo

-- 
Dipl.-Ing (FH) Thilo Fromm, MSc., Embedded Systems Developer
DResearch Digital Media Systems GmbH
Otto-Schmirgal-Str. 3, D-10319 Berlin, Germany
Amtsgericht: Berlin Charlottenburg, HRB:54412
Tel: +49 (30) 515 932 228   mailto:t.fromm at dresearch.de
Fax: +49 (30) 515 932 77 http://www.dresearch.de