[RFC] Kernel version numbering scheme change - Kernel

This is a discussion on [RFC] Kernel version numbering scheme change - Kernel ; On Fri, 17 Oct 2008, Giacomo A. Catenazzi wrote: > Greg KH wrote: >> We number the kernel based on the year, and the numbers of releases we >> have done this year: >> YEAR.NUMBER.MINOR_RELEASE >> >> For example, the ...

+ Reply to Thread
Page 4 of 6 FirstFirst ... 2 3 4 5 6 LastLast
Results 61 to 80 of 111

Thread: [RFC] Kernel version numbering scheme change

  1. Re: [RFC] Kernel version numbering scheme change

    On Fri, 17 Oct 2008, Giacomo A. Catenazzi wrote:

    > Greg KH wrote:
    >> We number the kernel based on the year, and the numbers of releases we
    >> have done this year:
    >> YEAR.NUMBER.MINOR_RELEASE
    >>
    >> For example, the first release in 2009 would be called:
    >> 2009.0.0
    >> The second:
    >> 2009.1.0
    >>
    >> If we want to be a bit more "non-zero-counting" friendly: we can start
    >> at "1" for the number:
    >> 2009.1.0 for the first release
    >> 2009.2.0 for the second.
    >>
    >> Then the stable releases can increment the minor number:
    >> 2009.1.1 for the first stable release
    >> 2009.1.2 for the second.
    >> and so on.
    >>
    >> Benefits of this is it more accuratly represents to people just how old
    >> the kernel they are currently running is (2.6.9 would be have been
    >> 2004.9.0 on this naming scheme.)
    >>
    >> Yes, we can handle the major/minor macros in the kernel to provide a
    >> compatible number so that automated scripts will not break, that's not a
    >> big deal.
    >>
    >> Any thoughts?

    >
    > What about:
    > - rc releases: a 2009.5.0-rc4 become suddenly 2010.0.0-rc5 ?


    three options

    1. change it as you state based on it slipping

    2. 2009.5.0-rc4 goes to 2009.5.0-rc5 in January and we just accept a minor
    'oops' on the version number

    3. 2009.5.0-rc4 goes to 2009.5.0-rc5 in January becouse we base the number
    on when the merge window opened, not when it's released.

    personally I think 3 is the clearest to explain to people, but I don't
    like 1 (it's not that bad, but it leaves a lot of mail in archives and bug
    reports listing the 2009.5.0 version number when no such version was ever
    released)

    > - a stable version in January of a kernel released in December
    > still has the old year? (I hope yes, but it could confuse users.)


    absolutly, the stable version is the Nth revision of the kernel that was
    released in December, it doesn't matter when the stable release happened
    (similar to the 2.6.16.X kernels that have been released)

    > - when (if) we need a big innovative (or incompatible) kernel
    > change, how to mark old and new kernels?


    they are marked in the release announcemnts, and code that cares can do
    'is version > 2009.5' logic.

    this sort of test is done today by software so that they can enable better
    functionality on newer kernels, the size of the difference shouldn't
    matter.

    David Lang

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [RFC] Kernel version numbering scheme change

    Greg KH wrote:
    >>
    >> I think it's both visually cumbersome and has the problem that it is harder
    >> to predict future releases. The first problem can be dealt with by simply
    >> subtracting 2000 from the year (Altera uses this scheme for their EDA
    >> tools, and I didn't realize it for quite a while because it looked so
    >> natural), but the second is still a problem.

    >
    > What is the "problem" of predicting future releases? What relies on the
    > actual number being "correct" some random time in the future?
    >


    We already have the 2.6.28-rc series; and we are already talking about
    2.6.29 features.

    We *really* don't want 2008.3-rc4 to be followed by 2009.1-rc5. That is
    the kind of stuff that make script makers want to strangle developers
    alive with their own intestines.

    -hpa
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. 2.6.28-rc1 --> 2.8.0-rc1; 2.6.27.y --> 2.6.28 [Re: [RFC] Kernel version numbering scheme change]

    On Sat, Oct 18, 2008 at 12:18:58AM -0700, H. Peter Anvin wrote:
    > Greg KH wrote:
    > >>
    > >>I think it's both visually cumbersome and has the problem that it is
    > >>harder to predict future releases. The first problem can be dealt with
    > >>by simply subtracting 2000 from the year (Altera uses this scheme for
    > >>their EDA tools, and I didn't realize it for quite a while because it
    > >>looked so natural), but the second is still a problem.

    > >
    > >What is the "problem" of predicting future releases? What relies on the
    > >actual number being "correct" some random time in the future?
    > >

    >
    > We already have the 2.6.28-rc series; and we are already talking about
    > 2.6.29 features.


    Well, Linus hasn't yet changed SUBLEVEL or EXTRAVERSION[*]. But Adrian has
    already stated that he will support what is known as 2.6.27 for a long time.
    What about Linus naming the next release 2.8.0 (and move on with 2.8.1,
    2.8.2, ... with no special meaning to the numbers), so instead of 2.6.28-rc1
    it's 2.8.0-rc1. And once Adrian takes over from the -stable team, he could
    release 2.6.28, 2.6.29 and so on when he thinks a new minor number is
    appropriate, such as Willy intends to release 2.4.37.

    Best,
    Dominik

    [*] Actually, it might be helpful if the very first commit after a
    release were to change SUBLEVEL to the next number and EXTRAVERSION to "pre"
    or something else, so that /lib/modules/2.6.y/ and the initramfs isn't then
    overwritten by the sometimes rough builds between 2.6.y and 2.6.(y+1)-rc1.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: 2.6.28-rc1 --> 2.8.0-rc1; 2.6.27.y --> 2.6.28 [Re: [RFC] Kernel version numbering scheme change]

    On Sat, 18 Oct 2008, Dominik Brodowski wrote:

    > Well, Linus hasn't yet changed SUBLEVEL or EXTRAVERSION[*]. But Adrian
    > has already stated that he will support what is known as 2.6.27 for a
    > long time. What about Linus naming the next release 2.8.0 (and move on
    > with 2.8.1, 2.8.2, ... with no special meaning to the numbers), so
    > instead of 2.6.28-rc1 it's 2.8.0-rc1. And once Adrian takes over from
    > the -stable team, he could release 2.6.28, 2.6.29 and so on when he
    > thinks a new minor number is appropriate, such as Willy intends to
    > release 2.4.37.


    Unless we change the meaning of the numbers, I see little reason to bump
    to 2.8.

    The only reason for change would be to merge 2.6 into 3, so we don't need
    2.6.29, 2.6.29.1, but instead we go to 3.0, 3.0.1, 3.0.2 and then
    3.1-rc1 becomes 3.1 and 3.1.1 is the next patch of it, and then
    3.2-rc1 etc. I don't see a problem to go over 9 on the second number
    either, so 3.23-rc1 is fine.

    Makes it one less number to describe what kernel one is talking about.
    Saying 2.6.29.2 is a bit cumbersome, I'd much prefer 3.0.2.

    --
    Mikael Abrahamsson email: swmike@swm.pp.se
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [RFC] Kernel version numbering scheme change

    On Fri, Oct 17, 2008 at 01:16:38AM -0700, Steven Noonan wrote:
    > I believe some of Adrian's concerns are valid. Userspace programs will
    > indeed break, largely because some depend on build-time and run-time
    > checks for the kernel version being >=2.6.0 or >=2.4.0 and so forth. I
    > suspect the best way to prove userspace breakage would be to make a
    > branch of the kernel with a new versioning scheme (8.10, 2008.10,
    > whatever) and use that as the installed kernel while building a Gentoo
    > system. I suspect you'd see massive breakage.


    The breakage is expected of course but should remain minor. It has
    always existed, when switching from 2.0 to 2.1, then 2.1 to 2.2,
    assuming that 2.2 was equivalent to 2.1.XX for some tools (remember
    knfsd ?), then from 2.2 to 2.3, then to assume that 2.4 was roughly
    equal to some 2.3.XX for some tools, then 2.5.XX then 2.6. Now some
    tools know that all 2.6 are not equivalent and they add new checks
    as versions appear.

    It will not be a problem. Some versions of some tools will certainly
    break at some point, but these are the ones used to check for a given
    platform, and it is normal for them to evolve and follow new releases.

    I know I have some build scripts packaging one way for 2.4 and another
    way for 2.6. Should initramfs not work anymore for instance, I'd have
    to rethink the process for more recent 2.6 anyway. It is possible that
    I'll have to do this with the recent firmware changes.

    Some tools which already assume that all 2.6 are equivalent will one
    day or another have to refine their checks after kernel feature
    removals which we're not allowed to complain about (eg: some modules).

    So updating tools to add support for new versions is not a major problem
    because it will eventually happen anyway.

    > I think a version numbering system change would be OK (though I
    > wouldn't very much -like- it), so long as there was a way for
    > userspace software to be able to differentiate between a kernel with
    > the old versioning system and the new versioning system.
    >
    > I think perhaps a better option in the long run is to start a v2.7
    > tree and figure out some Cool New Stuff(tm) to implement, keeping
    > consistency with the current versioning scheme.


    It would require tools updates as well.

    Willy

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [RFC] Kernel version numbering scheme change

    On Fri, Oct 17, 2008 at 02:44:09PM -0700, Greg KH wrote:
    > On Fri, Oct 17, 2008 at 08:47:23PM +0100, Alan Cox wrote:
    > > > And that's my point here, do we want to change the current numbering
    > > > scheme as people have expressed annoyances of the current one.

    > >
    > > But any new scheme will be just as annoying to someone and it messes up
    > > existing documentation, understanding and risks breaking third party
    > > tools.
    > >
    > > Is it really worth the hassle, plus we'll have to change again if we use
    > > date/times because once we are shipping Linux out to Alpha Centauri with
    > > colonists there will be serious problems trying to compute the effect of
    > > tau on release numbering ...

    >
    > Sure, but by then, the 2.6.521 release will be out and we could fix it
    > up by finally going to 3.0
    >
    > Seriously, am I the only one that is getting annoyed by our version
    > numbers? If so, I can live with it, but I got the feeling that I wasn't
    > alone here.


    No you're not. I am too. Maybe we're both more annoyed than majority
    because we're mostly dealing with 4-numbers versions.

    I remember having recently suggested someone to test 2.6.37, doing a
    confusion between 2.4.37 and 2.6.27. I have already tagged kernels
    with wrong versions, having to fix by hand afterwards. It's really
    cumbersome some times.

    I remember it became really boring in 2.1.X days when X got past 99.

    IMHO, having a small number of small digits is the way to go. Using
    1 or 2 digits for the major and 1 for the minor is fine. After 3.9, you
    go to version 4.0. Anyway, there are so many changes between versions
    these days that any new versions could justify a major change (eg:
    check the size of the 2.6.27 patch).

    With versions from 1.1 to 9.9, you can go as high as 88 versions,
    which is about 22 years of development at current pace. After that,
    we can simply turn to 10.0 and not break anything.

    It's also easier for users. Check how many non-kernel techies around you
    know all 3 digits of the version they use. It's easier to remember 4.3
    than it is to remember 2.6.27.

    If we can stick to something like this, we can easily use the 3rd number
    for the stable release. We would then have MAJOR.MINOR.PATCHRELEASE and
    keep extraversion for -rc etc... The syntax does not change, thus limiting
    the breakage and the change in habits.

    Regards,
    Willy

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [RFC] Kernel version numbering scheme change

    On Fri, Oct 17, 2008 at 11:56:04AM +0300, Adrian Bunk wrote:
    > On Fri, Oct 17, 2008 at 12:55:44AM -0700, Greg KH wrote:
    > > On Fri, Oct 17, 2008 at 09:47:51AM +0300, Adrian Bunk wrote:
    > >...
    > > > Packages are built in a chroot with the correct release installed.

    > >
    > > Then why would this break if they are being built against the correct,
    > > older, kernel?

    >
    > How could you build userspace "against a kernel"?
    >
    > sys_*uname() returns the version of the running kernel.


    Which is why you don't want your build scripts to rely on that, but
    on the target kernel version instead. It's quite common in distros
    to patch makefiles and build scripts to force some constants instead
    of calls to nasty or misplaced commands. Uname certainly is one of
    them.

    > > But not against the proper kernel it will be run on, which sounds
    > > broken.

    >
    > Building software in a chroot is a common thing if you don't want to
    > setup a dedicated machine for a build environment (and all these hyped
    > virtualization solutions tend to not support architectures like alpha
    > or parisc).


    The chroot is OK when you want to maintain a few packages once in
    a while (eg: have it on your notebook to build packages for your
    customers' various distros). But it's not suited to maintain full
    distros, nor to cross-compile.

    > The OpenSSL 0.9.8 config script is existing userspace, and it will
    > break.


    And ? All distros shipping version 0.9.8 with a current kernel will
    have no problem because they backport fixes only. Once the new kernel
    is out, openssl will release a minor update with a few fixes and features,
    one of them being tagged as "support for Linux 2.8 and above". New distros
    will then have no trouble shipping a standard openssl with a standard
    kernel. All software have always worked like this, I really don't see
    the problem Adrian.

    > That is one example that "Will" definitely break (no matter how broken
    > or how easy to fix it is).


    What makes you think that current 0.9.8g will work on 2.6.521 ? One day
    you might have to upgrade your openssl anyway. What is important is that
    the upgrade follows a smooth path. Adding a two-liner patch in a minor
    release to support new versions is smooth.

    > > And hey, if it's a problem, just fix userspace reporting to always say
    > > we are the 2.6.30 release and go on our merry way, perhaps providing
    > > another sysctl if it's really needed (glibc probably wants it, so it
    > > would be easy to add.)
    > >
    > > That's just a minor technical thing that can be trivially fixed _IF_ we
    > > decide it is something that we want to do.

    >
    > If we do not continue to report the correct version in sys_*uname()
    > (and therefore in "uname -r") we break standard POSIX behavior.


    I would not like it if uname -r would not report real version. I'd
    better get a tool to force the version if this is needed (ala cpuid).
    It reminds me that I had this for years under DOS :-)

    Regards,
    Willy

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [RFC] Kernel version numbering scheme change

    On Sat, Oct 18, 2008 at 11:01:18AM +0200, Willy Tarreau wrote:
    > On Fri, Oct 17, 2008 at 11:56:04AM +0300, Adrian Bunk wrote:
    >...
    > > Building software in a chroot is a common thing if you don't want to
    > > setup a dedicated machine for a build environment (and all these hyped
    > > virtualization solutions tend to not support architectures like alpha
    > > or parisc).

    >
    > The chroot is OK when you want to maintain a few packages once in
    > a while (eg: have it on your notebook to build packages for your
    > customers' various distros). But it's not suited to maintain full
    > distros,


    You claim Debian was not a full distro?

    > nor to cross-compile.


    Scratchbox [1], e.g. used for building the software in Nokias Internet
    Tablets [2] or the ARM Linux Internet Platform [3], is a chrooted
    cross-compilation environment.

    Yes, it works.

    And since a few years everyone can buy devices running software built
    inside Scratchbox chroots.

    > > The OpenSSL 0.9.8 config script is existing userspace, and it will
    > > break.

    >
    > And ? All distros shipping version 0.9.8 with a current kernel will
    > have no problem because they backport fixes only. Once the new kernel
    > is out, openssl will release a minor update with a few fixes and features,
    > one of them being tagged as "support for Linux 2.8 and above". New distros
    > will then have no trouble shipping a standard openssl with a standard
    > kernel. All software have always worked like this, I really don't see
    > the problem Adrian.


    Since Debian has a "support a release until one year after the next
    release" policy, Debian will at some point in the future build security
    fixes for OpenSSL 0.9.8g (shipped with Debian 5.0) in chroots on
    autobuilders running Debian 6.0 (runing kernel 2010.2.6).

    > > That is one example that "Will" definitely break (no matter how broken
    > > or how easy to fix it is).

    >
    > What makes you think that current 0.9.8g will work on 2.6.521 ?
    >...


    Userspace ABIs of the kernel are usually stable.

    There might be special cases like the year 2038 problem, but usually
    breaking an ABI software like OpenSSL uses would be considered a grave
    regression. [4]

    > Regards,
    > Willy


    cu
    Adrian

    [1] http://scratchbox.org/
    [2] http://maemo.org/
    [3] http://linux.onarm.com/
    [4] note that the value of the kernel version number is not strictly
    a userspace ABI - but changing it in unexpected ways will break
    existing software

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [RFC] Kernel version numbering scheme change

    Hi Adrian,

    this is becoming off-topic, but there are some points which need to be
    addressed. Please if you want to reply afterwards, be kind to strip the
    CC list.

    On Sat, Oct 18, 2008 at 01:04:01PM +0300, Adrian Bunk wrote:
    > On Sat, Oct 18, 2008 at 11:01:18AM +0200, Willy Tarreau wrote:
    > > On Fri, Oct 17, 2008 at 11:56:04AM +0300, Adrian Bunk wrote:
    > >...
    > > > Building software in a chroot is a common thing if you don't want to
    > > > setup a dedicated machine for a build environment (and all these hyped
    > > > virtualization solutions tend to not support architectures like alpha
    > > > or parisc).

    > >
    > > The chroot is OK when you want to maintain a few packages once in
    > > a while (eg: have it on your notebook to build packages for your
    > > customers' various distros). But it's not suited to maintain full
    > > distros,

    >
    > You claim Debian was not a full distro?


    I'm not judging that, they build like they want. If they want to build
    on the final target and have as many build machines as they support,
    it's their problem. It's just very amateurish. I wouldn't like to be
    the guy building the full distro in a chroot on an embedded ARM or MIPS
    just because it's the target.

    > > nor to cross-compile.

    >
    > Scratchbox [1], e.g. used for building the software in Nokias Internet
    > Tablets [2] or the ARM Linux Internet Platform [3], is a chrooted
    > cross-compilation environment.
    >
    > Yes, it works.


    I'm not saying it does not work, I'm saying it's far from being practical
    when you want to support multiple architectures or targets, and that it
    will do nasty things under you without letting you know.

    > And since a few years everyone can buy devices running software built
    > inside Scratchbox chroots.
    >
    > > > The OpenSSL 0.9.8 config script is existing userspace, and it will
    > > > break.

    > >
    > > And ? All distros shipping version 0.9.8 with a current kernel will
    > > have no problem because they backport fixes only. Once the new kernel
    > > is out, openssl will release a minor update with a few fixes and features,
    > > one of them being tagged as "support for Linux 2.8 and above". New distros
    > > will then have no trouble shipping a standard openssl with a standard
    > > kernel. All software have always worked like this, I really don't see
    > > the problem Adrian.

    >
    > Since Debian has a "support a release until one year after the next
    > release" policy, Debian will at some point in the future build security
    > fixes for OpenSSL 0.9.8g (shipped with Debian 5.0) in chroots on
    > autobuilders running Debian 6.0 (runing kernel 2010.2.6).


    The process you're describing is frighteningly broken. You're basically
    telling me that the day openssl automatically detects and enables a
    feature in the debian build environment, it will automatically enable
    it for the target environment ? This is pure non-sense. If they build
    like that, they'd better keep old boxes running the same distro as the
    target to maintain stable releases, or it's urgent to stay away from
    their stable versions as soon as you're aware they switched the build
    machine ! I hope they don't build 32-bit x86 from 64-bit systems if
    they proceed like this...

    A build environment is what it is, a build environment. It contains
    compilers, shells to run scripts, various interpreters and build tools,
    possibily debuggers and editors, versionning systems, etc...

    The target environment has nothing to do with the build environment.
    It's the environment the binary will run on. If some project does
    auto-detection of the build environment assuming it's the same as
    the target, you have to force it to the target environment, and not
    to dress up the build environment to look like it is the target one.

    For instance, I would be very angry if I built a project which
    automatically selected the use of epoll() for 2.4 target just
    because I'm building on 2.6. And in fact, this seldom happens,
    and setting a few variables or even patching configure or makefile
    is enough to fix the issue (and it is the right thing to do).

    > > > That is one example that "Will" definitely break (no matter how broken
    > > > or how easy to fix it is).

    > >
    > > What makes you think that current 0.9.8g will work on 2.6.521 ?
    > >...

    >
    > Userspace ABIs of the kernel are usually stable.


    Yes but they are not necessarily forward-compatible. If openssl believes
    some feature is present in 2.6.521 because 521 is bigger than 233, you
    will build a broken package which will not work with any distro running
    your long-term 2.6.27 which does not have the feature introduced in .233.

    Again, chroot builds are cool for *some* things. I too do use them a lot.
    But they're very dangerous and must not be used for everything. And when
    you know how to fix packages so that chroot is not a problem, then you
    know how to fix the package not to require a chroot.

    Willy

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [RFC] Kernel version numbering scheme change

    On Sat, Oct 18, 2008 at 01:08:26PM +0200, Willy Tarreau wrote:
    > Hi Adrian,


    Hi Willy,

    > this is becoming off-topic, but there are some points which need to be
    > addressed. Please if you want to reply afterwards, be kind to strip the
    > CC list.


    sorry, but you can't publically spread misinformation (and even repeat
    wrong things I already replied to earlier in this thread) and then
    demand to not have the reply public.

    > On Sat, Oct 18, 2008 at 01:04:01PM +0300, Adrian Bunk wrote:
    > > On Sat, Oct 18, 2008 at 11:01:18AM +0200, Willy Tarreau wrote:
    > > > On Fri, Oct 17, 2008 at 11:56:04AM +0300, Adrian Bunk wrote:
    > > >...
    > > > > Building software in a chroot is a common thing if you don't want to
    > > > > setup a dedicated machine for a build environment (and all these hyped
    > > > > virtualization solutions tend to not support architectures like alpha
    > > > > or parisc).
    > > >
    > > > The chroot is OK when you want to maintain a few packages once in
    > > > a while (eg: have it on your notebook to build packages for your
    > > > customers' various distros). But it's not suited to maintain full
    > > > distros,

    > >
    > > You claim Debian was not a full distro?

    >
    > I'm not judging that, they build like they want. If they want to build
    > on the final target and have as many build machines as they support,
    > it's their problem. It's just very amateurish.


    Debian does it, it works, and there's nothing amateurish about it - it's
    much easier than coping with all the problems faced with when trying to
    cross-compile > 12.000 source packages.

    With <= 3 build machines per architecture.

    > I wouldn't like to be
    > the guy building the full distro in a chroot on an embedded ARM or MIPS
    > just because it's the target.


    It's incremental, only a small amount of packages gets changed each day.

    > > > nor to cross-compile.

    > >
    > > Scratchbox [1], e.g. used for building the software in Nokias Internet
    > > Tablets [2] or the ARM Linux Internet Platform [3], is a chrooted
    > > cross-compilation environment.
    > >
    > > Yes, it works.

    >
    > I'm not saying it does not work, I'm saying it's far from being practical
    > when you want to support multiple architectures or targets, and that it
    > will do nasty things under you without letting you know.


    Scratchbox easily allows switching between targets, no matter which
    architectures they are for.

    Can you describe the problems you have experienced more precisely?

    > > And since a few years everyone can buy devices running software built
    > > inside Scratchbox chroots.
    > >
    > > > > The OpenSSL 0.9.8 config script is existing userspace, and it will
    > > > > break.
    > > >
    > > > And ? All distros shipping version 0.9.8 with a current kernel will
    > > > have no problem because they backport fixes only. Once the new kernel
    > > > is out, openssl will release a minor update with a few fixes and features,
    > > > one of them being tagged as "support for Linux 2.8 and above". New distros
    > > > will then have no trouble shipping a standard openssl with a standard
    > > > kernel. All software have always worked like this, I really don't see
    > > > the problem Adrian.

    > >
    > > Since Debian has a "support a release until one year after the next
    > > release" policy, Debian will at some point in the future build security
    > > fixes for OpenSSL 0.9.8g (shipped with Debian 5.0) in chroots on
    > > autobuilders running Debian 6.0 (runing kernel 2010.2.6).

    >
    > The process you're describing is frighteningly broken. You're basically
    > telling me that the day openssl automatically detects and enables a
    > feature in the debian build environment, it will automatically enable
    > it for the target environment ?
    >...
    > A build environment is what it is, a build environment. It contains
    > compilers, shells to run scripts, various interpreters and build tools,
    > possibily debuggers and editors, versionning systems, etc...


    The build environment in the chroot is the correct release.

    But the kernel returns the kernel version in sys_*uname().

    > > > > That is one example that "Will" definitely break (no matter how broken
    > > > > or how easy to fix it is).
    > > >
    > > > What makes you think that current 0.9.8g will work on 2.6.521 ?
    > > >...

    > >
    > > Userspace ABIs of the kernel are usually stable.

    >
    > Yes but they are not necessarily forward-compatible. If openssl believes
    > some feature is present in 2.6.521 because 521 is bigger than 233, you
    > will build a broken package which will not work with any distro running
    > your long-term 2.6.27 which does not have the feature introduced in .233.


    I already addressed this previously in this thread:

    I'm not even sure whether OpenSSL actually does anything with the
    information: The script comes from the Apache foundation and
    claims to be "Similar to config.guess but much, much smaller."

    >...
    > And when
    > you know how to fix packages so that chroot is not a problem, then you
    > know how to fix the package not to require a chroot.


    That's complete bull****:

    Packages do not require fixes for being built inside a chroot.

    Given:
    - some software package of a foobar program
    - Scratchbox on an x86 host
    - an ARM target that mounts the target filesystem from the host

    host # ./configure && make && make install
    target # foobar

    The build system of the software thinks it gets built on the target
    architecture.

    And due to transparent usage of qemu or sbrsh it also works when the
    package uses a program built for the target during the build.
    No matter whether the build system of the package knows anything about
    cross-compilation.

    > Willy


    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [RFC] Kernel version numbering scheme change

    On Sat, Oct 18, 2008 at 02:50:38PM +0300, Adrian Bunk wrote:
    > > this is becoming off-topic, but there are some points which need to be
    > > addressed. Please if you want to reply afterwards, be kind to strip the
    > > CC list.

    >
    > sorry, but you can't publically spread misinformation (and even repeat
    > wrong things I already replied to earlier in this thread) and then
    > demand to not have the reply public.


    It's not about not having it public, it's about not flooding people's
    mailboxes with off-topic mails.

    > > On Sat, Oct 18, 2008 at 01:04:01PM +0300, Adrian Bunk wrote:
    > > I'm not judging that, they build like they want. If they want to build
    > > on the final target and have as many build machines as they support,
    > > it's their problem. It's just very amateurish.

    >
    > Debian does it, it works, and there's nothing amateurish about it - it's
    > much easier than coping with all the problems faced with when trying to
    > cross-compile > 12.000 source packages.


    It's easier as long as you have one build environment very close to the
    target, which tends not to be possible anymore as time passes or for too
    small devices.

    > With <= 3 build machines per architecture.


    and why not have 3 build machines at all ?

    > > > Scratchbox [1], e.g. used for building the software in Nokias Internet
    > > > Tablets [2] or the ARM Linux Internet Platform [3], is a chrooted
    > > > cross-compilation environment.
    > > >
    > > > Yes, it works.

    > >
    > > I'm not saying it does not work, I'm saying it's far from being practical
    > > when you want to support multiple architectures or targets, and that it
    > > will do nasty things under you without letting you know.

    >
    > Scratchbox easily allows switching between targets, no matter which
    > architectures they are for.
    >
    > Can you describe the problems you have experienced more precisely?


    Adrian, don't try to make me look like dumb by asking for specific
    problems. Problems range from auto-detection of kernel version to
    enable or disable feature X or Y, to endian detection and bit width
    detection. If you don't believe me, it's just that you're used to
    build completely OS-agnostic packages, which is perfectly fine, but
    that doesn't seem to be completely the case given that you're feeling
    you will get annoyed by breaking the openssl BUILD environment if
    you make it run on a different kernel. *That* is the funny part,
    since this build environment should not even require to run on Linux
    at all! And believe me, I know that openssl is boring to build due
    to many hard-coded things which require patching (mainly paths if my
    memory is correct). But once that's done, it's done forever.

    > > A build environment is what it is, a build environment. It contains
    > > compilers, shells to run scripts, various interpreters and build tools,
    > > possibily debuggers and editors, versionning systems, etc...

    >
    > The build environment in the chroot is the correct release.


    No it isn't because you're saying that some of the packages check for
    kernel version which is not the right one. So if you move your chroot
    to another machine, it is susceptible to break because it relies on
    the host's kernel version. So your chroot is not your build environment,
    it's just part of it.

    > > > Userspace ABIs of the kernel are usually stable.

    > >
    > > Yes but they are not necessarily forward-compatible. If openssl believes
    > > some feature is present in 2.6.521 because 521 is bigger than 233, you
    > > will build a broken package which will not work with any distro running
    > > your long-term 2.6.27 which does not have the feature introduced in .233.

    >
    > I already addressed this previously in this thread:
    >
    > I'm not even sure whether OpenSSL actually does anything with the
    > information: The script comes from the Apache foundation and
    > claims to be "Similar to config.guess but much, much smaller."


    You addressed it only for openssl and apache 1.3, that you used as
    examples to object to a change of changing kernel version numbering
    scheme. So do you have other examples of packages like this which
    might break and might be more sensible to build environment's kernel
    version ? Because if only apache 1.3 and openssl 0.9.8g are sensible,
    the fix will be really quick using something like this in your build
    scripts and makefiles :

    uname() {
    if [ -n "$KERNEL_TARGET" ]; then
    echo $KERNEL_TARGET
    else
    /bin/uname "$@"
    fi
    }

    And BTW, if your build environment mimmics so well the target except
    for uname, let's fix its uname tool to reflect the target version !

    > > And when
    > > you know how to fix packages so that chroot is not a problem, then you
    > > know how to fix the package not to require a chroot.

    >
    > That's complete bull****:
    >
    > Packages do not require fixes for being built inside a chroot.
    >
    > Given:
    > - some software package of a foobar program
    > - Scratchbox on an x86 host
    > - an ARM target that mounts the target filesystem from the host
    >
    > host # ./configure && make && make install
    > target # foobar
    >
    > The build system of the software thinks it gets built on the target
    > architecture.


    Quite cool stuff, but I'm really not interested. Having been beat by
    a number of packages which try to run target environment commands
    during the build when not set for cross-compile, I'd expect pretty
    random results.

    > And due to transparent usage of qemu or sbrsh it also works when the
    > package uses a program built for the target during the build.
    > No matter whether the build system of the package knows anything about
    > cross-compilation.


    That's the design error you're trying to fix by pushing constraints on
    the kernel.

    Willy

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [RFC] Kernel version numbering scheme change

    On Sat, Oct 18, 2008 at 02:28:51PM +0200, Willy Tarreau wrote:
    > On Sat, Oct 18, 2008 at 02:50:38PM +0300, Adrian Bunk wrote:
    >...
    > > > > Scratchbox [1], e.g. used for building the software in Nokias Internet
    > > > > Tablets [2] or the ARM Linux Internet Platform [3], is a chrooted
    > > > > cross-compilation environment.
    > > > >
    > > > > Yes, it works.
    > > >
    > > > I'm not saying it does not work, I'm saying it's far from being practical
    > > > when you want to support multiple architectures or targets, and that it
    > > > will do nasty things under you without letting you know.

    > >
    > > Scratchbox easily allows switching between targets, no matter which
    > > architectures they are for.
    > >
    > > Can you describe the problems you have experienced more precisely?

    >
    > Adrian, don't try to make me look like dumb by asking for specific
    > problems. Problems range from auto-detection of kernel version to


    > enable or disable feature X or Y,


    Works inside Scratchbox.

    > to endian detection and bit width


    Works inside Scratchbox.

    > detection. If you don't believe me, it's just that you're used to
    > build completely OS-agnostic packages,


    That's completely wrong.

    > which is perfectly fine, but
    > that doesn't seem to be completely the case given that you're feeling
    > you will get annoyed by breaking the openssl BUILD environment if
    > you make it run on a different kernel. *That* is the funny part,
    > since this build environment should not even require to run on Linux
    > at all!


    10 years ago someone wrote his own version of config.guess, and assumed
    kernel developers would always use sane versions.

    This doesn't make it Linux-specific.

    >...
    > > > A build environment is what it is, a build environment. It contains
    > > > compilers, shells to run scripts, various interpreters and build tools,
    > > > possibily debuggers and editors, versionning systems, etc...

    > >
    > > The build environment in the chroot is the correct release.

    >
    > No it isn't because you're saying that some of the packages check for
    > kernel version which is not the right one. So if you move your chroot
    > to another machine, it is susceptible to break because it relies on
    > the host's kernel version. So your chroot is not your build environment,
    > it's just part of it.


    The version is one of the few things the kernel leaks inside a chroot.

    > > > > Userspace ABIs of the kernel are usually stable.
    > > >
    > > > Yes but they are not necessarily forward-compatible. If openssl believes
    > > > some feature is present in 2.6.521 because 521 is bigger than 233, you
    > > > will build a broken package which will not work with any distro running
    > > > your long-term 2.6.27 which does not have the feature introduced in .233.

    > >
    > > I already addressed this previously in this thread:
    > >
    > > I'm not even sure whether OpenSSL actually does anything with the
    > > information: The script comes from the Apache foundation and
    > > claims to be "Similar to config.guess but much, much smaller."

    >
    > You addressed it only for openssl and apache 1.3, that you used as
    > examples to object to a change of changing kernel version numbering
    > scheme. So do you have other examples of packages like this which
    > might break and might be more sensible to build environment's kernel
    > version ? Because if only apache 1.3 and openssl 0.9.8g are sensible,
    > the fix will be really quick using something like this in your build
    > scripts and makefiles :
    >...
    > And BTW, if your build environment mimmics so well the target except
    > for uname, let's fix its uname tool to reflect the target version !


    The problem has nothing to do with any build environments or chroots.

    A "just for fun" change of the version number will break existing
    programs, and that will cause various problems for various people.

    > > > And when
    > > > you know how to fix packages so that chroot is not a problem, then you
    > > > know how to fix the package not to require a chroot.

    > >
    > > That's complete bull****:
    > >
    > > Packages do not require fixes for being built inside a chroot.
    > >
    > > Given:
    > > - some software package of a foobar program
    > > - Scratchbox on an x86 host
    > > - an ARM target that mounts the target filesystem from the host
    > >
    > > host # ./configure && make && make install
    > > target # foobar
    > >
    > > The build system of the software thinks it gets built on the target
    > > architecture.

    >
    > Quite cool stuff, but I'm really not interested. Having been beat by
    > a number of packages which try to run target environment commands
    > during the build when not set for cross-compile, I'd expect pretty
    > random results.


    The build system of the package thinks it gets compiled natively - that
    avoids exactly the problems you describe.

    And trying to run a target binary when building on the host *does work*
    inside Scratchbox. Please *read* what I wrote directly below:

    > > And due to transparent usage of qemu or sbrsh it also works when the
    > > package uses a program built for the target during the build.
    > > No matter whether the build system of the package knows anything about
    > > cross-compilation.

    >...
    > Willy


    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: [RFC] Kernel version numbering scheme change

    On Sat, Oct 18, 2008 at 04:48:33PM +0300, Adrian Bunk wrote:
    > 10 years ago someone wrote his own version of config.guess, and assumed
    > kernel developers would always use sane versions.


    And versions are not sane anymore. 1.0, 1.2, 2.0, 2.2 and 2.4 were branches
    where the 3rd digit indicated a patch level or a minor feature enhancement.
    Yes there were exceptions to that. 2.2.18 brought USB. 2.4.10 changed the
    VM, the list can be extended. But the principle was that $MAJOR.$MINOR
    could be relied on. It's not the case anymore. You have to check 3 numbers
    now if you want to check for some specific feature. I think that only /sys
    existence and the module loading method are constants across all 2.6.

    Getting back to something like $MAJOR.$MINOR would not change the original
    checks. New versions would have to be updated once in a while if needed,
    just like we'd have to if 2.6.29 brought a great change.

    I'm clearly not for anything depending on the date. But having 3.0 instead
    of 2.6.30, then 3.1, 3.2, ... would have no reason to break a model which
    has worked well for the last 15 years.

    > A "just for fun" change of the version number will break existing
    > programs, and that will cause various problems for various people.


    It's not "just for fun". You know I'm often more reluctant to changing than
    you are. But as Linus already pointed it out, numbers are becoming completely
    meaningless and it's a pain to enumerate them. You and I are both playing
    with 4-digit versions once in a while. Greg releases two such versions at
    once far more often than any of us. This versionning is already confusing.
    It's certainly not for fun that Greg brought that subject back.

    > > Quite cool stuff, but I'm really not interested. Having been beat by
    > > a number of packages which try to run target environment commands
    > > during the build when not set for cross-compile, I'd expect pretty
    > > random results.

    >
    > The build system of the package thinks it gets compiled natively - that
    > avoids exactly the problems you describe.


    Well, the way you describe it with all the magics ("thinks", "transparent",
    ....) is precisely what incites me to stay away from that. Autoconf is also
    made to make things more transparent, and what a mess... But I know you're
    attached to clean and reliable things, so I'll take a look at it to get my
    own opinion on the solution (not right now though).

    Willy

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: [RFC] Kernel version numbering scheme change


    On Thursday 2008-10-16 03:34, david@lang.hm wrote:
    > On Thu, 16 Oct 2008, Thorsten Leemhuis wrote:
    >> On 16.10.2008 02:25, Greg KH wrote:
    >>
    >> Hence people that write a lot of articles about things that happen in linux
    >> land (like LWN.net or I do) would be forced to write sentences like "[...]the
    >> kernel that will become 2008.3 or 2009.0 will have feature foo that works
    >> like this[...]". That will get really confusing if you read those articles
    >> half a year later -- especially if that kernel became 2008.3 in the end,
    >> because foo in 2009.0 might already look quite different again...

    >
    > pick a name when the merge window opens


    Hell no, we're not a distro.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: [RFC] Kernel version numbering scheme change


    On Thursday 2008-10-16 05:15, Hans J. Koch wrote:
    >On Wed, Oct 15, 2008 at 05:25:09PM -0700, Greg KH wrote:
    >>
    >> Benefits of this is it more accuratly represents to people just how old
    >> the kernel they are currently running is (2.6.9 would be have been
    >> 2004.9.0 on this naming scheme.)

    >
    >That would be a nice advantage, especially in embedded land where
    >industry people frequently use ancient kernels. OTOH, those people also
    >still use Windows 2000 without realizing what the "2000" implies.


    (It implies 1999.)

    If people do not even realize what "Windows 2000" means,
    how would they be able to realize what "Linux 2004" would!

    Also, Windows long moved away from the year-numbering (XP, Vista, and
    the next is probably going to be an increasing integer), because
    Redmond probably figured that people don't realize anything.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: [RFC] Kernel version numbering scheme change


    On Wed 2008-10-15 17:25:09 -0700, Grek KH wrote to Linus Torvalds:
    >
    >You brought this topic up a few months ago, and passed it off as
    >something we would discuss at the kernel summit.


    On Friday 2008-10-17 17:44, Greg KH wrote:
    >
    >Seriously, am I the only one that is getting annoyed by our version
    >numbers? If so, I can live with it, but I got the feeling that I wasn't
    >alone here.



    If there is a real discontent about the version number
    it would have already been changed.
    Given that nothing happened, it seems it is tolerated.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: [RFC] Kernel version numbering scheme change


    On Friday 2008-10-17 17:44, Greg KH wrote:
    >
    >Sure, but by then, the 2.6.521 release will be out and we could fix it
    >up by finally going to 3.0


    There will be no 2.6.521. Simply because the LINUX_VERSION_CODE
    macro only allows for the 2nd and 3rd position to be 8 bits.

    (Hooray, which means we will _automatically_ get a 2.7 after at most
    229 more releases, or 3.0 after at most 63973 more releases!^{*})


    {*} If you find off-by-one errors, keep them.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: [RFC] Kernel version numbering scheme change

    On Fri, 17 Oct 2008, david@lang.hm wrote:

    > > Surely some scripts will start to break as soon as the third number gets
    > > three digits.

    > we've had three digit numbers in the third position before (2.3 and 2.5
    > went well past three digits IIRC)


    Did we? I only recall 2.5.7[something] and 2.3.5[something] (plus special
    2.3.99 release).

    > > Actually, I thought we could continue to use a w.x.y.z numbering
    > > scheme, but in such a way that:
    > > w = ($year - 2000) / 10 + 2 (so that we start from 2)
    > > x = $year % 10
    > > y = (number of major release in $year)
    > > z = (number of stable version for major release w.x.y)
    > > Then, the first major release in 2009 would be 2.9.1 and its first
    > > -stable "child" would become 2.9.1.1. In turn, the first major
    > > release in 2010 could be 3.0.1 and so on.

    > if you want the part of the version number to increment based on the year,
    > just make it the year and don't complicate things.


    In addition to that, having the kernel version dependent on year doesn't
    really seem to make much sense to me. Simply said, I don't see any
    relation of kernel source code contents to the current date in whatever
    calendar system.

    And 2.x+1.y-rcZ+1 immediately following 2.x.y-rcZ really hurts my eyes

    --
    Jiri Kosina
    SUSE Labs

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: [RFC] Kernel version numbering scheme change

    On Sat, 18 Oct 2008, Willy Tarreau wrote:

    > confusion between 2.4.37 and 2.6.27. I have already tagged kernels with
    > wrong versions, having to fix by hand afterwards. It's really cumbersome
    > some times.


    But this is only because you are maintaining a source code that is several
    years old, right? Would maintaining a series numbered 2002.x.y make your
    situation a lot better? Do you think you'd never make typo '2002 instead
    of 2006' any more?

    Or how would you distingiush the kernel tree you are maintaing from the
    one Linus is maintaining?

    --
    Jiri Kosina
    SUSE Labs

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: [RFC] Kernel version numbering scheme change

    On Sun, 19 Oct 2008, Jiri Kosina wrote:

    > On Fri, 17 Oct 2008, david@lang.hm wrote:
    >
    >>> Surely some scripts will start to break as soon as the third number gets
    >>> three digits.

    >> we've had three digit numbers in the third position before (2.3 and 2.5
    >> went well past three digits IIRC)

    >
    > Did we? I only recall 2.5.7[something] and 2.3.5[something] (plus special
    > 2.3.99 release).


    I know some versions have (I remember deploying 2.1.116 on a box across
    the country with no way to get at it afterwords)

    >>> Actually, I thought we could continue to use a w.x.y.z numbering
    >>> scheme, but in such a way that:
    >>> w = ($year - 2000) / 10 + 2 (so that we start from 2)
    >>> x = $year % 10
    >>> y = (number of major release in $year)
    >>> z = (number of stable version for major release w.x.y)
    >>> Then, the first major release in 2009 would be 2.9.1 and its first
    >>> -stable "child" would become 2.9.1.1. In turn, the first major
    >>> release in 2010 could be 3.0.1 and so on.

    >> if you want the part of the version number to increment based on the year,
    >> just make it the year and don't complicate things.

    >
    > In addition to that, having the kernel version dependent on year doesn't
    > really seem to make much sense to me. Simply said, I don't see any
    > relation of kernel source code contents to the current date in whatever
    > calendar system.


    it does give an indication of how out of date the kernel you are using is.

    > And 2.x+1.y-rcZ+1 immediately following 2.x.y-rcZ really hurts my eyes


    that I agree with.

    David Lang
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 4 of 6 FirstFirst ... 2 3 4 5 6 LastLast