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<[email protected]> >>> 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:[email protected] Fax: +49 30 515932-299 Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058 _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
