Am 25.02.2011 08:51, schrieb Khem Raj: > 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.
That would definitely be my preferred solution. I hope the distro maintainers can handle this. > 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* Just my second choice. 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
