On 02/25/2011 11:22 AM, Frans Meulenbroeks wrote: > 2011/2/25 Khem Raj <[email protected]>: >> On Thu, Feb 24, 2011 at 11:40 PM, Steffen Sledz <[email protected]> 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 <[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). >>>>> >>>>> 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.
Sounds good to me. > (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* 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
