* linux-libc-headers version (reloaded) @ 2011-02-15 10:41 Steffen Sledz 2011-02-15 14:12 ` Andreas Oberritter 0 siblings, 1 reply; 23+ messages in thread From: Steffen Sledz @ 2011-02-15 10:41 UTC (permalink / raw) To: openembedded-devel While doing some maintenance for our hipox machine i hit a problem which was discussed controversially a few months before on this ML[1] but was not solved completely in my opinion. The basic question was if it is valid to use PREFERRED_VERSION_linux-libc-headers higher than the kernel version (like e.g angstrom-2008.1 does). After some research on that topic i really believe this is not allowed. My strongest argument is the kernel docu itself: "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] Also i did not found a linux distribution providing kernel headers newer than the kernel (whilst there are some with kernel headers older than the used kernel, e.g. openSUSE 11.3 with latest updates). So i think the way the Ångström distribution handles this is wrong. If PREFERRED_VERSION_linux-libc-headers is set to 2.6.31 no kernel older than 2.6.31 should be allowed to guarantee the full functionality of all programs! [1] <http://thread.gmane.org/gmane.comp.handhelds.openembedded/32375> [2] Documentation/make/headers_install.txt Steffen -- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:sledz@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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-15 10:41 linux-libc-headers version (reloaded) Steffen Sledz @ 2011-02-15 14:12 ` Andreas Oberritter 2011-02-15 14:37 ` Tom Rini ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Andreas Oberritter @ 2011-02-15 14:12 UTC (permalink / raw) To: openembedded-devel 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? Regards, Andreas ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-15 14:12 ` Andreas Oberritter @ 2011-02-15 14:37 ` Tom Rini 2011-02-15 14:50 ` Steffen Sledz 2011-02-15 15:01 ` Phil Blundell 2 siblings, 0 replies; 23+ messages in thread From: Tom Rini @ 2011-02-15 14:37 UTC (permalink / raw) To: openembedded-devel On 02/15/2011 07:12 AM, Andreas Oberritter wrote: > 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? Right. But other things can start to rely on the kernel interfaces (where it's allowed to) as well, and often don't do the various hoops to be forwards compatible at run time. -- Tom Rini Mentor Graphics Corporation ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-15 14:12 ` Andreas Oberritter 2011-02-15 14:37 ` Tom Rini @ 2011-02-15 14:50 ` Steffen Sledz 2011-02-18 9:55 ` Steffen Sledz 2011-02-15 15:01 ` Phil Blundell 2 siblings, 1 reply; 23+ messages in thread From: Steffen Sledz @ 2011-02-15 14:50 UTC (permalink / raw) To: openembedded-devel 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. Steffen -- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:sledz@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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-15 14:50 ` Steffen Sledz @ 2011-02-18 9:55 ` Steffen Sledz 2011-02-18 15:30 ` Khem Raj 0 siblings, 1 reply; 23+ messages in thread From: Steffen Sledz @ 2011-02-18 9:55 UTC (permalink / raw) To: openembedded-devel; +Cc: koen 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). Regards, Steffen -- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:sledz@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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-18 9:55 ` Steffen Sledz @ 2011-02-18 15:30 ` Khem Raj 2011-02-24 13:30 ` Steffen Sledz 0 siblings, 1 reply; 23+ messages in thread From: Khem Raj @ 2011-02-18 15:30 UTC (permalink / raw) To: openembedded-devel; +Cc: koen On Fri, Feb 18, 2011 at 1:55 AM, Steffen Sledz <sledz@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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-18 15:30 ` Khem Raj @ 2011-02-24 13:30 ` Steffen Sledz 2011-02-24 14:57 ` Andreas Oberritter 2011-02-25 21:05 ` Tom Rini 0 siblings, 2 replies; 23+ messages in thread From: Steffen Sledz @ 2011-02-24 13:30 UTC (permalink / raw) To: Khem Raj; +Cc: koen, openembedded-devel On 02/18/2011 04:30 PM, Khem Raj wrote: > On Fri, Feb 18, 2011 at 1:55 AM, Steffen Sledz <sledz@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). 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. Steffen -- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:sledz@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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-24 13:30 ` Steffen Sledz @ 2011-02-24 14:57 ` Andreas Oberritter 2011-02-25 7:40 ` Steffen Sledz 2011-02-25 21:05 ` Tom Rini 1 sibling, 1 reply; 23+ messages in thread From: Andreas Oberritter @ 2011-02-24 14:57 UTC (permalink / raw) To: openembedded-devel 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 <sledz@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). > > 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. IIRC, the kernel policy is to disallow incompatible changes to user interfaces, so applications compiled against new headers generally don't magically start to use new interfaces, unless their code gets adapted to them. Can you please shed some light on which kernel interfaces are actually causing problems? Btw.: The availability of syscalls not only depends on the kernel version but on the kernel configuration, too. For example, if you compile a kernel without CONFIG_EPOLL, epoll will still be available in the kernel headers and will be found by autotools etc. But it will alwyas return ENOSYS. We certainly can't provide matching linux-libc-headers to avoid that. Regards, Andreas ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-24 14:57 ` Andreas Oberritter @ 2011-02-25 7:40 ` Steffen Sledz 2011-02-25 7:51 ` Khem Raj 2011-02-25 11:36 ` Andreas Oberritter 0 siblings, 2 replies; 23+ messages in thread From: Steffen Sledz @ 2011-02-25 7:40 UTC (permalink / raw) To: openembedded-devel 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 <sledz@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). >> >> 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)! Steffen -- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:sledz@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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-25 7:40 ` Steffen Sledz @ 2011-02-25 7:51 ` Khem Raj 2011-02-25 8:14 ` Steffen Sledz ` (2 more replies) 2011-02-25 11:36 ` Andreas Oberritter 1 sibling, 3 replies; 23+ messages in thread From: Khem Raj @ 2011-02-25 7:51 UTC (permalink / raw) To: openembedded-devel On Thu, Feb 24, 2011 at 11:40 PM, Steffen Sledz <sledz@dresearch.de> 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 <sledz@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). >>> >>> 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. 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:sledz@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 > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-25 7:51 ` Khem Raj @ 2011-02-25 8:14 ` Steffen Sledz 2011-02-25 10:22 ` Frans Meulenbroeks 2011-02-25 12:11 ` Andreas Oberritter 2 siblings, 0 replies; 23+ messages in thread From: Steffen Sledz @ 2011-02-25 8:14 UTC (permalink / raw) To: Khem Raj; +Cc: Koen Kooi, openembedded-devel Am 25.02.2011 08:51, schrieb Khem Raj: > On Thu, Feb 24, 2011 at 11:40 PM, Steffen Sledz <sledz@dresearch.de> 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 <sledz@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). >>>> >>>> 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:sledz@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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-25 7:51 ` Khem Raj 2011-02-25 8:14 ` Steffen Sledz @ 2011-02-25 10:22 ` Frans Meulenbroeks 2011-02-25 11:37 ` Steffen Sledz 2011-02-25 12:11 ` Andreas Oberritter 2 siblings, 1 reply; 23+ messages in thread From: Frans Meulenbroeks @ 2011-02-25 10:22 UTC (permalink / raw) To: openembedded-devel 2011/2/25 Khem Raj <raj.khem@gmail.com>: > On Thu, Feb 24, 2011 at 11:40 PM, Steffen Sledz <sledz@dresearch.de> 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 <sledz@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). >>>> >>>> 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. (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* > > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-25 10:22 ` Frans Meulenbroeks @ 2011-02-25 11:37 ` Steffen Sledz 0 siblings, 0 replies; 23+ messages in thread From: Steffen Sledz @ 2011-02-25 11:37 UTC (permalink / raw) To: openembedded-devel; +Cc: Koen Kooi On 02/25/2011 11:22 AM, Frans Meulenbroeks wrote: > 2011/2/25 Khem Raj <raj.khem@gmail.com>: >> On Thu, Feb 24, 2011 at 11:40 PM, Steffen Sledz <sledz@dresearch.de> 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 <sledz@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). >>>>> >>>>> 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:sledz@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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-25 7:51 ` Khem Raj 2011-02-25 8:14 ` Steffen Sledz 2011-02-25 10:22 ` Frans Meulenbroeks @ 2011-02-25 12:11 ` Andreas Oberritter 2011-02-25 17:28 ` Khem Raj 2 siblings, 1 reply; 23+ messages in thread From: Andreas Oberritter @ 2011-02-25 12:11 UTC (permalink / raw) To: openembedded-devel On 02/25/2011 08:51 AM, Khem Raj wrote: > 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. The .config does not have any influence on the generated linux-libc-headers by definition. linux-libc-headers must not contain any CONFIG_* statements, because they are meant to be independent of it. The kernel config is not available to linux-libc-headers after all. The point I was trying to make is that feature detection at compile time is impossible, if the feature can be disabled by the kernel config (which is the case for epoll and inotify, which in turn were the examples discussed on the mailing list in May 2010). You need to do runtime tests in programs intended to be portable. Regards, Andreas ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-25 12:11 ` Andreas Oberritter @ 2011-02-25 17:28 ` Khem Raj 2011-02-25 20:02 ` Phil Blundell 2011-02-26 12:47 ` Andreas Oberritter 0 siblings, 2 replies; 23+ messages in thread From: Khem Raj @ 2011-02-25 17:28 UTC (permalink / raw) To: openembedded-devel On Fri, Feb 25, 2011 at 4:11 AM, Andreas Oberritter <obi@opendreambox.org> wrote: > On 02/25/2011 08:51 AM, Khem Raj wrote: >> 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. > > The .config does not have any influence on the generated yes thats right > linux-libc-headers by definition. linux-libc-headers must not contain > any CONFIG_* statements, because they are meant to be independent of it. > The kernel config is not available to linux-libc-headers after all. > > The point I was trying to make is that feature detection at compile time > is impossible, if the feature can be disabled by the kernel config > (which is the case for epoll and inotify, which in turn were the > examples discussed on the mailing list in May 2010). You need to do > runtime tests in programs intended to be portable. which may not be easy to do for cross compiled packages unless they are patches to make this test dynamic > > Regards, > Andreas > > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-25 17:28 ` Khem Raj @ 2011-02-25 20:02 ` Phil Blundell 2011-02-25 20:48 ` Khem Raj 2011-02-26 12:47 ` Andreas Oberritter 1 sibling, 1 reply; 23+ messages in thread From: Phil Blundell @ 2011-02-25 20:02 UTC (permalink / raw) To: openembedded-devel On Fri, 2011-02-25 at 09:28 -0800, Khem Raj wrote: > On Fri, Feb 25, 2011 at 4:11 AM, Andreas Oberritter > <obi@opendreambox.org> wrote: > > The point I was trying to make is that feature detection at compile time > > is impossible, if the feature can be disabled by the kernel config > > (which is the case for epoll and inotify, which in turn were the > > examples discussed on the mailing list in May 2010). You need to do > > runtime tests in programs intended to be portable. > > which may not be easy to do for cross compiled packages unless they are patches > to make this test dynamic Isn't a runtime test dynamic by definition? I'm not quite sure how cross-compiling is relevant to this. p. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-25 20:02 ` Phil Blundell @ 2011-02-25 20:48 ` Khem Raj 0 siblings, 0 replies; 23+ messages in thread From: Khem Raj @ 2011-02-25 20:48 UTC (permalink / raw) To: openembedded-devel On Fri, Feb 25, 2011 at 12:02 PM, Phil Blundell <philb@gnu.org> wrote: > On Fri, 2011-02-25 at 09:28 -0800, Khem Raj wrote: >> On Fri, Feb 25, 2011 at 4:11 AM, Andreas Oberritter >> <obi@opendreambox.org> wrote: >> > The point I was trying to make is that feature detection at compile time >> > is impossible, if the feature can be disabled by the kernel config >> > (which is the case for epoll and inotify, which in turn were the >> > examples discussed on the mailing list in May 2010). You need to do >> > runtime tests in programs intended to be portable. >> >> which may not be easy to do for cross compiled packages unless they are patches >> to make this test dynamic > > Isn't a runtime test dynamic by definition? yes thats what I meant I'm not quite sure how > cross-compiling is relevant to this. fact that we may not be able to do the runtime tests to configure a package while cross compiling is what I was thinking of > > p. > > > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-25 17:28 ` Khem Raj 2011-02-25 20:02 ` Phil Blundell @ 2011-02-26 12:47 ` Andreas Oberritter 2011-02-26 17:08 ` Khem Raj 1 sibling, 1 reply; 23+ messages in thread From: Andreas Oberritter @ 2011-02-26 12:47 UTC (permalink / raw) To: Khem Raj; +Cc: openembedded-devel On 02/25/2011 06:28 PM, Khem Raj wrote: > On Fri, Feb 25, 2011 at 4:11 AM, Andreas Oberritter > <obi@opendreambox.org> wrote: >> On 02/25/2011 08:51 AM, Khem Raj wrote: >>> 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. >> >> The .config does not have any influence on the generated > > yes thats right > >> linux-libc-headers by definition. linux-libc-headers must not contain >> any CONFIG_* statements, because they are meant to be independent of it. >> The kernel config is not available to linux-libc-headers after all. >> >> The point I was trying to make is that feature detection at compile time >> is impossible, if the feature can be disabled by the kernel config >> (which is the case for epoll and inotify, which in turn were the >> examples discussed on the mailing list in May 2010). You need to do >> runtime tests in programs intended to be portable. > > which may not be easy to do for cross compiled packages unless they are patches > to make this test dynamic That doesn't make any sense. Runtime tests aren't affected by any cross compilation issues. Runtime tests are dynamic by nature. Regards, Andreas ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-26 12:47 ` Andreas Oberritter @ 2011-02-26 17:08 ` Khem Raj 0 siblings, 0 replies; 23+ messages in thread From: Khem Raj @ 2011-02-26 17:08 UTC (permalink / raw) To: Andreas Oberritter; +Cc: openembedded-devel On Sat, Feb 26, 2011 at 4:47 AM, Andreas Oberritter <obi@opendreambox.org> wrote: > On 02/25/2011 06:28 PM, Khem Raj wrote: >> On Fri, Feb 25, 2011 at 4:11 AM, Andreas Oberritter >> <obi@opendreambox.org> wrote: >>> On 02/25/2011 08:51 AM, Khem Raj wrote: >>>> 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. >>> >>> The .config does not have any influence on the generated >> >> yes thats right >> >>> linux-libc-headers by definition. linux-libc-headers must not contain >>> any CONFIG_* statements, because they are meant to be independent of it. >>> The kernel config is not available to linux-libc-headers after all. >>> >>> The point I was trying to make is that feature detection at compile time >>> is impossible, if the feature can be disabled by the kernel config >>> (which is the case for epoll and inotify, which in turn were the >>> examples discussed on the mailing list in May 2010). You need to do >>> runtime tests in programs intended to be portable. >> >> which may not be easy to do for cross compiled packages unless they are patches >> to make this test dynamic > > That doesn't make any sense. Runtime tests aren't affected by any cross > compilation issues. Runtime tests are dynamic by nature. I think we are talking different things. I was talking about e.g. configure relying on result of a runtime test to enable some feature during compile time -Khem ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-25 7:40 ` Steffen Sledz 2011-02-25 7:51 ` Khem Raj @ 2011-02-25 11:36 ` Andreas Oberritter 1 sibling, 0 replies; 23+ messages in thread From: Andreas Oberritter @ 2011-02-25 11:36 UTC (permalink / raw) To: Steffen Sledz; +Cc: openembedded-devel On 02/25/2011 08:40 AM, Steffen Sledz 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 <sledz@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). >>> >>> 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. Sure. It's not possible to guarantee that all apps don't have severe bugs. But we can test and fix apps that are important to us. > 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). That's right, because programs using compile time detection of kernel features may not work. No other issues have been brought up yet. > This should be reason enough to avoid newer kernel headers (like all other linux distros do)! Non-embedded linux distros have different requirements and in general they ship only one kernel version for all targets. Btw., recently I tried to boot a rootfs built with kernel headers 2.6.18 with a 2.6.38-rc kernel. I don't know why, but it didn't work at all (running init failed). Rebuilding with kernel headers 2.6.37 allowed me to boot both kernels 2.6.18 and 2.6.38-rc. After all it's the distro's decision which headers to use, so I won't argue for or against any policy that Angström uses. But I'm interested in actual issues faced with old kernels running binaries compiled with new headers. Regards, Andreas ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-24 13:30 ` Steffen Sledz 2011-02-24 14:57 ` Andreas Oberritter @ 2011-02-25 21:05 ` Tom Rini 2011-02-26 16:14 ` Sledz, Steffen 1 sibling, 1 reply; 23+ messages in thread From: Tom Rini @ 2011-02-25 21:05 UTC (permalink / raw) To: openembedded-devel 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@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. -- Tom Rini Mentor Graphics Corporation ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-25 21:05 ` Tom Rini @ 2011-02-26 16:14 ` Sledz, Steffen 0 siblings, 0 replies; 23+ messages in thread From: Sledz, Steffen @ 2011-02-26 16:14 UTC (permalink / raw) To: openembedded-devel; +Cc: Koen Kooi 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@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@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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: linux-libc-headers version (reloaded) 2011-02-15 14:12 ` Andreas Oberritter 2011-02-15 14:37 ` Tom Rini 2011-02-15 14:50 ` Steffen Sledz @ 2011-02-15 15:01 ` Phil Blundell 2 siblings, 0 replies; 23+ messages in thread From: Phil Blundell @ 2011-02-15 15:01 UTC (permalink / raw) To: openembedded-devel On Tue, 2011-02-15 at 15:12 +0100, Andreas Oberritter wrote: > 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? Not quite, no. OLDEST_KERNEL is used to configure glibc's internal kernel compatibility code and doesn't have much to do with the headers. Under normal circumstances, glibc will include a bunch of compatibility functions which allow the same binary to work (up to a point) on a range of kernel versions. For example, sys_pselect6 was added, on arm at least, in 2.6.32, and if glibc finds itself running on an older kernel it will fall back to using sys_select instead. However, if you configure with --enable-kernel=2.6.32 then you are promising to glibc that it will never be used on an older kernel and this compatibility logic can be omitted: you will now just get a "kernel too old" error if you try to boot on 2.6.31 or lower. p. ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2011-02-26 17:10 UTC | newest] Thread overview: 23+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-02-15 10:41 linux-libc-headers version (reloaded) Steffen Sledz 2011-02-15 14:12 ` Andreas Oberritter 2011-02-15 14:37 ` Tom Rini 2011-02-15 14:50 ` Steffen Sledz 2011-02-18 9:55 ` Steffen Sledz 2011-02-18 15:30 ` Khem Raj 2011-02-24 13:30 ` Steffen Sledz 2011-02-24 14:57 ` Andreas Oberritter 2011-02-25 7:40 ` Steffen Sledz 2011-02-25 7:51 ` Khem Raj 2011-02-25 8:14 ` Steffen Sledz 2011-02-25 10:22 ` Frans Meulenbroeks 2011-02-25 11:37 ` Steffen Sledz 2011-02-25 12:11 ` Andreas Oberritter 2011-02-25 17:28 ` Khem Raj 2011-02-25 20:02 ` Phil Blundell 2011-02-25 20:48 ` Khem Raj 2011-02-26 12:47 ` Andreas Oberritter 2011-02-26 17:08 ` Khem Raj 2011-02-25 11:36 ` Andreas Oberritter 2011-02-25 21:05 ` Tom Rini 2011-02-26 16:14 ` Sledz, Steffen 2011-02-15 15:01 ` Phil Blundell
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.