[RFC] Kernel version numbering scheme change - Kernel

This is a discussion on [RFC] Kernel version numbering scheme change - Kernel ; On Thu, Oct 16, 2008 at 08:17:48AM -0700, Greg KH wrote: > On Thu, Oct 16, 2008 at 03:49:43PM +0300, Adrian Bunk wrote: >... > > If a distribution will try to autobuild an urgent OpenSSL security > > update ...

+ Reply to Thread
Page 2 of 6 FirstFirst 1 2 3 4 ... LastLast
Results 21 to 40 of 111

Thread: [RFC] Kernel version numbering scheme change

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

    On Thu, Oct 16, 2008 at 08:17:48AM -0700, Greg KH wrote:
    > On Thu, Oct 16, 2008 at 03:49:43PM +0300, Adrian Bunk wrote:
    >...
    > > If a distribution will try to autobuild an urgent OpenSSL security
    > > update for their stable release in a chroot on a machine running
    > > kernel 2009.2.3 they will surely love you for being responsible
    > > for this...

    >
    > Distros properly patch things and backport "urgent OpenSSL security
    > updates" to older versions of packages, so they would not run into this
    > problem.


    You didn't get my point.

    Let me make an example:

    The current Debian release will be supported until one year after the
    next release gets released.

    Someone from the Debian security team send a fixed package to the
    buildds.

    The buildds build packages in chroots.

    A buildd may run any Debian release.

    And it's perfectly normal that a buildd runs a more recent release of
    Debian than the one a package gets built for in a chroot.

    No matter what you claim, you suggest to break currently working setups.

    > Newer releases would run into this problem, but as almost all distros
    > have huge, easy to run, build systems, a change like this would show up
    > immediately and be fixed in a matter of hours, with the needed fixes
    > being pushed upstream to the various packages as needed.
    >
    > So I really don't think this is much of a problem.
    >...


    Using the same logic we could drop all legacy userspace ABIs
    immediately - after all, it should only be a matter of hours
    for a distribution to e.g. upgrade their glibc to 2.8 ...

    You cannot suggest to change something that is some kind of informal
    userspace ABI and the claim it was not much of a problem.

    I don't know what exactly would break, but various places in userspace
    would break in perhaps unexpected and strange ways, and this would cause
    many people quite a bit of headaches and work.

    And I don't see any *really* good reason that would justify such
    a change in the versioning.

    > thanks,
    >
    > greg k-h


    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/

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

    On Thu, Oct 16, 2008 at 08:47:26AM -0700, Greg KH wrote:
    > On Thu, Oct 16, 2008 at 11:30:53AM -0400, Bill Nottingham wrote:
    > > Greg KH (greg@kroah.com) said:
    > > > Distros properly patch things and backport "urgent OpenSSL security
    > > > updates" to older versions of packages, so they would not run into this
    > > > problem.
    > > >
    > > > Newer releases would run into this problem, but as almost all distros
    > > > have huge, easy to run, build systems, a change like this would show up
    > > > immediately and be fixed in a matter of hours, with the needed fixes
    > > > being pushed upstream to the various packages as needed.
    > > >
    > > > So I really don't think this is much of a problem.
    > > >
    > > > It's interesting that openssl doesn't just check for Linux 1.x and
    > > > assumes that Linux 9.23.12 will work just fine with what they are doing

    > >
    > > Is it really worth the effort of having any such upstream have to
    > > quickly patch and release, when the only benefit listed (earlier in
    > > this thread) was to inform people how old their kernel is?

    >
    > If we switch to a consecutive numbering scheme, which doesn't show the
    > "age" of the kernel, we would still have to patch such packages, so I
    > don't see the big difference.


    You miss the best alternative:

    Simply keep the status quo.

    > thanks,
    >
    > greg k-h


    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/

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

    On Thu, 16 Oct 2008, el es wrote:

    > H. Peter Anvin zytor.com> writes:
    >> el es wrote:

    > [snip]
    >>> - informative : the ww and tt numbers are the week numbers of when the actual
    >>>
    >>> release HAPPENED, not when it is predicted.
    >>>

    >>
    >> Which really sucks for dealing with future releases.
    >>

    >
    > Why ?
    > What do you mean by 'future releases' ?
    > Can you predict exactly when the next release will happen ? The current practice
    > of -rcX shows clearly you cannot.


    that's the point

    > Moreover, with my idea you could easily say, which stable release is still
    > supported (and how old its mainline really was) up to the week, which IMHO is
    > granular enough.


    huh?? kernels are not supported for X amount of time, so this isn't
    relevant information for support. kernels are 'supported' until some time
    after the next kernel is released.

    > Also you could for sure say, that e.g. a device/software that hit market in say
    > December this year, will be compatible with e.g. 2.09.XX+ - look at users POV.


    no you can't, the fact that a kernel was released in December and the
    product was released in November tells you nothing about the probability
    that that hardware is supported by that kernel.

    you can't even say that a kernel released in 2009 supports hardware
    released in 2007.

    David Lang

    > Current scheme is great, established and understandable, but sucks at this
    > point : for any product, be it hardware or software, you need to print both its
    > date of creation AND the minimum kernel that supports it. With my idea, it is
    > only the date you need.
    >
    >> -hpa
    >>

    >
    > Lukasz
    >
    >
    > --
    > 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/
    >

    --
    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: [RFC] Kernel version numbering scheme change

    >>>>> "Theodore" == Theodore Tso writes:

    Theodore> On Thu, Oct 16, 2008 at 04:26:19PM +0200, markus reichelt wrote:
    >> Why not just keep it? It has worked so far, and from a strictly
    >> end-user point of view I cannot see any advantages at all with a new
    >> scheme. The ideas mentioned so far don't cut it either.


    Theodore> I'd cast a vote for keeping it as well. "2.6" is actually a
    Theodore> great marker so that people know that it's highly likely the
    Theodore> version number is for the Linux kernel. Contrast "I'm
    Theodore> running 2.6.27" versus "I'm running 27" (huh, what does that
    Theodore> mean?) or "I'm running the 27 kernel" or "I'm running Linux
    Theodore> kernel version 27" or worse yet "I'm running 2008-03".
    Theodore> Something like "2.6.27" is just easier to say, and less
    Theodore> prone to misunderstanding/confusion.

    I dunno... I like the *idea* of a date string, but maybe it needs to
    be in parallel and not replace the 2.6.x we have currently? God knows
    a bunch of stuff is going to break when we get to 2.6.100 or 2.>6 or
    3.x or whatever.

    But, having something which encodes the release date into the version
    string would be useful as well. On my home debian box I get:

    > uname -a

    Linux jfsnew 2.6.26 #17 SMP Mon Jul 21 18:58:42 EDT 2008 i686 GNU/Linux

    So having "2.6.16 (2008/MM/DD) #17 ..." would be great with me. But
    people would need to think it through more carefully...

    John

    --
    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

    Theodore Tso writes:

    > On Thu, Oct 16, 2008 at 04:26:19PM +0200, markus reichelt wrote:
    >> Why not just keep it? It has worked so far, and from a strictly
    >> end-user point of view I cannot see any advantages at all with a new
    >> scheme. The ideas mentioned so far don't cut it either.

    >
    > I'd cast a vote for keeping it as well. "2.6" is actually a great
    > marker so that people know that it's highly likely the version number
    > is for the Linux kernel. Contrast "I'm running 2.6.27" versus "I'm
    > running 27" (huh, what does that mean?) or "I'm running the 27 kernel"
    > or "I'm running Linux kernel version 27" or worse yet "I'm running
    > 2008-03". Something like "2.6.27" is just easier to say, and less
    > prone to misunderstanding/confusion.
    >
    > Let's just leave things the way they are.


    My suggestion: When 2.6.28 is released, rename it to 2.8 (or 2.8.0).
    The next one will be 2.9, then 2.10 and so on. Today's 2.6.x.y will be
    2.8.y.

    It should minimise breakage of userspace programs.

    Or wait til 2.6.30, and rename that to 3.0.
    --
    Hilsen Harald.
    --
    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 Wednesday 15 October 2008 19:25:09 Greg KH wrote:
    > Hi,
    >
    > You brought this topic up a few months ago, and passed it off as
    > something we would discuss at the kernel summit. But that never
    > happened, so I figured I'd bring it up again here.
    >
    > So, as someone who constantly is dealing with kernel version numbers all
    > the time with the -stable trees, our current numbering scheme is a pain
    > a times. How about this proposal instead?


    I don't understand, what exactly is a pain about it? (I can't tell why a new
    one is better if you don't say what you're objecting to about the old one...)

    > 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.)


    Benefits is plural, but I seem to have missed the other ones. Or is that the
    only issue, wanting to put a more prominent "best if used by" date in the
    name ala Windows 95?

    Rob
    --
    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 Thu, Oct 16, 2008 at 11:35 PM, Theodore Tso wrote:
    > On Thu, Oct 16, 2008 at 04:26:19PM +0200, markus reichelt wrote:
    >> Why not just keep it? It has worked so far, and from a strictly
    >> end-user point of view I cannot see any advantages at all with a new
    >> scheme. The ideas mentioned so far don't cut it either.

    >
    > I'd cast a vote for keeping it as well. "2.6" is actually a great
    > marker so that people know that it's highly likely the version number
    > is for the Linux kernel. Contrast "I'm running 2.6.27" versus "I'm
    > running 27" (huh, what does that mean?) or "I'm running the 27 kernel"
    > or "I'm running Linux kernel version 27" or worse yet "I'm running
    > 2008-03". Something like "2.6.27" is just easier to say, and less
    > prone to misunderstanding/confusion.
    >
    > Let's just leave things the way they are.


    Agree.

    Additionally, we can add some range to x.y.z

    such as:

    x: 1-9
    y: 1-9
    z: 1-30

    so we can jumo to 2.7.1 after 2.6.30

    --
    Regards
    dave
    --
    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 Thu, Oct 16, 2008 at 07:46:02PM +0300, Adrian Bunk wrote:
    > On Thu, Oct 16, 2008 at 08:17:48AM -0700, Greg KH wrote:
    > > On Thu, Oct 16, 2008 at 03:49:43PM +0300, Adrian Bunk wrote:
    > >...
    > > > If a distribution will try to autobuild an urgent OpenSSL security
    > > > update for their stable release in a chroot on a machine running
    > > > kernel 2009.2.3 they will surely love you for being responsible
    > > > for this...

    > >
    > > Distros properly patch things and backport "urgent OpenSSL security
    > > updates" to older versions of packages, so they would not run into this
    > > problem.

    >
    > You didn't get my point.
    >
    > Let me make an example:
    >
    > The current Debian release will be supported until one year after the
    > next release gets released.
    >
    > Someone from the Debian security team send a fixed package to the
    > buildds.
    >
    > The buildds build packages in chroots.
    >
    > A buildd may run any Debian release.
    >
    > And it's perfectly normal that a buildd runs a more recent release of
    > Debian than the one a package gets built for in a chroot.


    So you are saying the Debian build system would build a package for an
    older release, on a system that is newer, and that build would be
    determining things based on the system it is built on, not what it is
    being built for?

    If so, then something is very broken already in the Debian build system
    and I think you have much bigger problems to worry about right now.

    For all other "sane" build systems that I know of, you build against the
    libraries/kernel/gcc/glibc/etc that you are wanting to support it for,
    not against some random-whatever-happened-to-be-installed-on-the-box.

    > No matter what you claim, you suggest to break currently working setups.


    No, you have described a broken setup.

    Now for new releases, yes, something might have to be changed, but that
    is when a sane distro would move to the newly named kernel, not
    affecting any old releases at all.

    Hope this helps,

    greg k-h
    --
    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

    On Thu, Oct 16, 2008 at 08:16:26PM +0300, Adrian Bunk wrote:
    > On Thu, Oct 16, 2008 at 08:47:26AM -0700, Greg KH wrote:
    > You miss the best alternative:
    >
    > Simply keep the status quo.


    I'd argue that is is a pain. Linus has expressed frustration with the
    current numbering scheme, and as someone who deals with kernel version
    numbers every single day, I too am mildly frustrated.

    I think the main reason why is just that small numbers are easier to
    keep track of in your mind. As we are ever increasing the version
    number, the release numbers feel like they are getting closer together,
    making them less distinguishable.

    For example, think of the following:
    2.6.5 vs. 2.6.9
    Your mind focuses on the 5 and 9, and in thinking about them, it is much
    easier to keep them apart.

    Now, try the same with:
    2.6.24 vs. 2.6.27
    You are repeating the tens digit, the "two", so it is a bit harder to
    distinguish things. After a few years of this, it gets more difficult

    So I proposed an alternative, YEAR.NUMBER. The year is easy to keep
    track of, and the release number is a small one, making it too easier to
    track and distinguish from each other:
    2009.1 vs. 2009.5
    or
    2010.2 vs. 2011.5
    It also means something that lets you remember back to what was going on
    for that release better, if you can easily place it within a specific
    time frame, which is important for those of us who work with different
    kernel versions all the time for different projects and backports and
    stable releases.

    If the number stays the same, my feeble brain will survive and I'll just
    rely on my huge spreadsheet of when specific kernels were released when
    to get along, and hopefully I will not make any more .26.5 releases when
    I mean .25.5 and such like I have in the past

    thanks,

    greg k-h
    --
    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 Thu, 16 Oct 2008 21:02:39 -0700, you wrote:

    >On Thu, Oct 16, 2008 at 08:16:26PM +0300, Adrian Bunk wrote:
    >> On Thu, Oct 16, 2008 at 08:47:26AM -0700, Greg KH wrote:
    >> You miss the best alternative:
    >>
    >> Simply keep the status quo.

    >
    >I'd argue that is is a pain. Linus has expressed frustration with the
    >current numbering scheme, and as someone who deals with kernel version
    >numbers every single day, I too am mildly frustrated.
    >
    >I think the main reason why is just that small numbers are easier to
    >keep track of in your mind. As we are ever increasing the version
    >number, the release numbers feel like they are getting closer together,
    >making them less distinguishable.
    >
    >For example, think of the following:
    > 2.6.5 vs. 2.6.9
    >Your mind focuses on the 5 and 9, and in thinking about them, it is much
    >easier to keep them apart.
    >
    >Now, try the same with:
    > 2.6.24 vs. 2.6.27
    >You are repeating the tens digit, the "two", so it is a bit harder to
    >distinguish things. After a few years of this, it gets more difficult
    >
    >So I proposed an alternative, YEAR.NUMBER. The year is easy to keep
    >track of, and the release number is a small one, making it too easier to
    >track and distinguish from each other:
    > 2009.1 vs. 2009.5
    >or
    > 2010.2 vs. 2011.5


    So add a 'RELEASEDATE = 2008-nn-nn' on line five of the top Makefile
    just under the 'NAME = Rotary Wombat' variation.

    Perhaps lose the leading '2.6.' when 2.6.30 comes around, give some
    warning to all that their scripts are gonna break with that release.

    Then you could play with low 3.0.0 numbers again

    Grant.

    >It also means something that lets you remember back to what was going on
    >for that release better, if you can easily place it within a specific
    >time frame, which is important for those of us who work with different
    >kernel versions all the time for different projects and backports and
    >stable releases.
    >
    >If the number stays the same, my feeble brain will survive and I'll just
    >rely on my huge spreadsheet of when specific kernels were released when
    >to get along, and hopefully I will not make any more .26.5 releases when
    >I mean .25.5 and such like I have in the past
    >
    >thanks,
    >
    >greg k-h

    --
    http://bugsplatter.id.au
    --
    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 Thu, 16 Oct 2008 21:02:39 -0700 Greg KH wrote:

    > On Thu, Oct 16, 2008 at 08:16:26PM +0300, Adrian Bunk wrote:
    > > On Thu, Oct 16, 2008 at 08:47:26AM -0700, Greg KH wrote:
    > > You miss the best alternative:
    > >
    > > Simply keep the status quo.

    >
    > I'd argue that is is a pain. Linus has expressed frustration with the
    > current numbering scheme, and as someone who deals with kernel version
    > numbers every single day, I too am mildly frustrated.
    >
    > I think the main reason why is just that small numbers are easier to
    > keep track of in your mind. As we are ever increasing the version
    > number, the release numbers feel like they are getting closer together,
    > making them less distinguishable.
    >
    > For example, think of the following:
    > 2.6.5 vs. 2.6.9
    > Your mind focuses on the 5 and 9, and in thinking about them, it is much
    > easier to keep them apart.
    >
    > Now, try the same with:
    > 2.6.24 vs. 2.6.27
    > You are repeating the tens digit, the "two", so it is a bit harder to
    > distinguish things. After a few years of this, it gets more difficult
    >
    > So I proposed an alternative, YEAR.NUMBER. The year is easy to keep
    > track of, and the release number is a small one, making it too easier to
    > track and distinguish from each other:
    > 2009.1 vs. 2009.5
    > or
    > 2010.2 vs. 2011.5
    > It also means something that lets you remember back to what was going on
    > for that release better, if you can easily place it within a specific
    > time frame, which is important for those of us who work with different
    > kernel versions all the time for different projects and backports and
    > stable releases.
    >
    > If the number stays the same, my feeble brain will survive and I'll just
    > rely on my huge spreadsheet of when specific kernels were released when
    > to get along, and hopefully I will not make any more .26.5 releases when
    > I mean .25.5 and such like I have in the past


    Nah, that can/will still happen (for someone).

    I still fail to see what is br0ken and needs to be fixed...

    ---
    ~Randy
    --
    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 Thu, Oct 16, 2008 at 08:47:17PM -0700, Greg KH wrote:
    > On Thu, Oct 16, 2008 at 07:46:02PM +0300, Adrian Bunk wrote:
    > > On Thu, Oct 16, 2008 at 08:17:48AM -0700, Greg KH wrote:
    > > > On Thu, Oct 16, 2008 at 03:49:43PM +0300, Adrian Bunk wrote:
    > > >...
    > > > > If a distribution will try to autobuild an urgent OpenSSL security
    > > > > update for their stable release in a chroot on a machine running
    > > > > kernel 2009.2.3 they will surely love you for being responsible
    > > > > for this...
    > > >
    > > > Distros properly patch things and backport "urgent OpenSSL security
    > > > updates" to older versions of packages, so they would not run into this
    > > > problem.

    > >
    > > You didn't get my point.
    > >
    > > Let me make an example:
    > >
    > > The current Debian release will be supported until one year after the
    > > next release gets released.
    > >
    > > Someone from the Debian security team send a fixed package to the
    > > buildds.
    > >
    > > The buildds build packages in chroots.
    > >
    > > A buildd may run any Debian release.
    > >
    > > And it's perfectly normal that a buildd runs a more recent release of
    > > Debian than the one a package gets built for in a chroot.

    >
    > So you are saying the Debian build system would build a package for an
    > older release, on a system that is newer,


    Packages are built in a chroot with the correct release installed.

    > and that build would be
    > determining things based on the system it is built on, not what it is
    > being built for?


    No.

    In the example I gave it is OpenSSL that parses the version number of
    the kernel.

    > If so, then something is very broken already in the Debian build system
    > and I think you have much bigger problems to worry about right now.
    >
    > For all other "sane" build systems that I know of, you build against the
    > libraries/kernel/gcc/glibc/etc that you are wanting to support it for,
    > not against some random-whatever-happened-to-be-installed-on-the-box.


    Building in a chroot is hardly "very broken".

    And it does build against the correct
    libraries/kernel headers/gcc/glibc/etc .

    Did you ever use a chroot?


    And this was just one example.

    What does userspace with the kernel version returned by GDTIOCTL_OSVERS?
    I don't know whether it just displays the number, or whether it
    determines anything based on it.

    Or what else might parse the version number?

    What if some proprietary userspace software like Skype or Flash or
    whatever parses the kernel version number at runtime and barfs on
    2009.2.3 in a way similar to the OpenSSL build system?

    WHAT YOU SUGGEST WILL BREAK EXISTING USERSPACE SOFTWARE.

    Please admit this fact.


    >...
    > Hope this helps,
    >
    > greg k-h


    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 Fri, Oct 17, 2008 at 09:47:51AM +0300, Adrian Bunk wrote:
    > On Thu, Oct 16, 2008 at 08:47:17PM -0700, Greg KH wrote:
    > > On Thu, Oct 16, 2008 at 07:46:02PM +0300, Adrian Bunk wrote:
    > > > On Thu, Oct 16, 2008 at 08:17:48AM -0700, Greg KH wrote:
    > > > > On Thu, Oct 16, 2008 at 03:49:43PM +0300, Adrian Bunk wrote:
    > > > >...
    > > > > > If a distribution will try to autobuild an urgent OpenSSL security
    > > > > > update for their stable release in a chroot on a machine running
    > > > > > kernel 2009.2.3 they will surely love you for being responsible
    > > > > > for this...
    > > > >
    > > > > Distros properly patch things and backport "urgent OpenSSL security
    > > > > updates" to older versions of packages, so they would not run into this
    > > > > problem.
    > > >
    > > > You didn't get my point.
    > > >
    > > > Let me make an example:
    > > >
    > > > The current Debian release will be supported until one year after the
    > > > next release gets released.
    > > >
    > > > Someone from the Debian security team send a fixed package to the
    > > > buildds.
    > > >
    > > > The buildds build packages in chroots.
    > > >
    > > > A buildd may run any Debian release.
    > > >
    > > > And it's perfectly normal that a buildd runs a more recent release of
    > > > Debian than the one a package gets built for in a chroot.

    > >
    > > So you are saying the Debian build system would build a package for an
    > > older release, on a system that is newer,

    >
    > 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?

    > > and that build would be
    > > determining things based on the system it is built on, not what it is
    > > being built for?

    >
    > No.
    >
    > In the example I gave it is OpenSSL that parses the version number of
    > the kernel.


    The running kernel, with the expectation that this is the kernel it is
    going to be running on after it is built, right? Sounds like to ensure
    this is correct, you better be building it on the kernel that you are
    going to run it on, or its build process is broken.

    > > If so, then something is very broken already in the Debian build system
    > > and I think you have much bigger problems to worry about right now.
    > >
    > > For all other "sane" build systems that I know of, you build against the
    > > libraries/kernel/gcc/glibc/etc that you are wanting to support it for,
    > > not against some random-whatever-happened-to-be-installed-on-the-box.

    >
    > Building in a chroot is hardly "very broken".
    >
    > And it does build against the correct
    > libraries/kernel headers/gcc/glibc/etc .


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

    > Did you ever use a chroot?


    There's a fine line between being condencending and asking a valid
    question. I'll assume you are not being condencending here...

    Yes, of course.

    > And this was just one example.
    >
    > What does userspace with the kernel version returned by GDTIOCTL_OSVERS?


    I don't know, hopefully not much if anything. glibc does things with
    it, but that is usually to turn off emulation of various features that
    are in the kernel in newer releases.

    > I don't know whether it just displays the number, or whether it
    > determines anything based on it.
    >
    > Or what else might parse the version number?
    >
    > What if some proprietary userspace software like Skype or Flash or
    > whatever parses the kernel version number at runtime and barfs on
    > 2009.2.3 in a way similar to the OpenSSL build system?
    >
    > WHAT YOU SUGGEST WILL BREAK EXISTING USERSPACE SOFTWARE.
    >
    > Please admit this fact.


    "Might" I will give you, "Will", I will not without actually testing.

    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.

    And to get back to the original point, Linus had expressed such an
    interest in changing this a while ago, so I was bringing it up, saying
    that I to thought we should change this, and proposed one such naming
    change.

    That has nothing to do with the "OMG You killed SKYPE!" hysteria that
    you are proposing here. Please separate the two issues as they are
    totally different.

    thanks,

    greg "take a chill pill" k-h
    --
    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 Fri, Oct 17, 2008 at 12:55 AM, Greg KH wrote:
    > On Fri, Oct 17, 2008 at 09:47:51AM +0300, Adrian Bunk wrote:
    >> On Thu, Oct 16, 2008 at 08:47:17PM -0700, Greg KH wrote:
    >> > On Thu, Oct 16, 2008 at 07:46:02PM +0300, Adrian Bunk wrote:
    >> > > On Thu, Oct 16, 2008 at 08:17:48AM -0700, Greg KH wrote:
    >> > > > On Thu, Oct 16, 2008 at 03:49:43PM +0300, Adrian Bunk wrote:
    >> > > >...
    >> > > > > If a distribution will try to autobuild an urgent OpenSSL security
    >> > > > > update for their stable release in a chroot on a machine running
    >> > > > > kernel 2009.2.3 they will surely love you for being responsible
    >> > > > > for this...
    >> > > >
    >> > > > Distros properly patch things and backport "urgent OpenSSL security
    >> > > > updates" to older versions of packages, so they would not run into this
    >> > > > problem.
    >> > >
    >> > > You didn't get my point.
    >> > >
    >> > > Let me make an example:
    >> > >
    >> > > The current Debian release will be supported until one year after the
    >> > > next release gets released.
    >> > >
    >> > > Someone from the Debian security team send a fixed package to the
    >> > > buildds.
    >> > >
    >> > > The buildds build packages in chroots.
    >> > >
    >> > > A buildd may run any Debian release.
    >> > >
    >> > > And it's perfectly normal that a buildd runs a more recent release of
    >> > > Debian than the one a package gets built for in a chroot.
    >> >
    >> > So you are saying the Debian build system would build a package for an
    >> > older release, on a system that is newer,

    >>
    >> 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?
    >
    >> > and that build would be
    >> > determining things based on the system it is built on, not what it is
    >> > being built for?

    >>
    >> No.
    >>
    >> In the example I gave it is OpenSSL that parses the version number of
    >> the kernel.

    >
    > The running kernel, with the expectation that this is the kernel it is
    > going to be running on after it is built, right? Sounds like to ensure
    > this is correct, you better be building it on the kernel that you are
    > going to run it on, or its build process is broken.
    >
    >> > If so, then something is very broken already in the Debian build system
    >> > and I think you have much bigger problems to worry about right now.
    >> >
    >> > For all other "sane" build systems that I know of, you build against the
    >> > libraries/kernel/gcc/glibc/etc that you are wanting to support it for,
    >> > not against some random-whatever-happened-to-be-installed-on-the-box.

    >>
    >> Building in a chroot is hardly "very broken".
    >>
    >> And it does build against the correct
    >> libraries/kernel headers/gcc/glibc/etc .

    >
    > But not against the proper kernel it will be run on, which sounds
    > broken.
    >
    >> Did you ever use a chroot?

    >
    > There's a fine line between being condencending and asking a valid
    > question. I'll assume you are not being condencending here...
    >
    > Yes, of course.
    >
    >> And this was just one example.
    >>
    >> What does userspace with the kernel version returned by GDTIOCTL_OSVERS?

    >
    > I don't know, hopefully not much if anything. glibc does things with
    > it, but that is usually to turn off emulation of various features that
    > are in the kernel in newer releases.
    >
    >> I don't know whether it just displays the number, or whether it
    >> determines anything based on it.
    >>
    >> Or what else might parse the version number?
    >>
    >> What if some proprietary userspace software like Skype or Flash or
    >> whatever parses the kernel version number at runtime and barfs on
    >> 2009.2.3 in a way similar to the OpenSSL build system?
    >>
    >> WHAT YOU SUGGEST WILL BREAK EXISTING USERSPACE SOFTWARE.
    >>
    >> Please admit this fact.

    >
    > "Might" I will give you, "Will", I will not without actually testing.
    >
    > 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.
    >
    > And to get back to the original point, Linus had expressed such an
    > interest in changing this a while ago, so I was bringing it up, saying
    > that I to thought we should change this, and proposed one such naming
    > change.
    >
    > That has nothing to do with the "OMG You killed SKYPE!" hysteria that
    > you are proposing here. Please separate the two issues as they are
    > totally different.
    >
    > thanks,
    >
    > greg "take a chill pill" k-h


    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.

    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.

    - Steven
    --
    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 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.

    > > > and that build would be
    > > > determining things based on the system it is built on, not what it is
    > > > being built for?

    > >
    > > No.
    > >
    > > In the example I gave it is OpenSSL that parses the version number of
    > > the kernel.

    >
    > The running kernel, with the expectation that this is the kernel it is
    > going to be running on after it is built, right? Sounds like to ensure
    > this is correct, you better be building it on the kernel that you are
    > going to run it on, or its build process is broken.


    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."

    BTW: Apache 1.3 seems to ship and use the same script.

    >...
    > > Building in a chroot is hardly "very broken".
    > >
    > > And it does build against the correct
    > > libraries/kernel headers/gcc/glibc/etc .

    >
    > 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).

    >...
    > > And this was just one example.
    > >
    > > What does userspace with the kernel version returned by GDTIOCTL_OSVERS?

    >
    > I don't know, hopefully not much if anything. glibc does things with
    > it, but that is usually to turn off emulation of various features that
    > are in the kernel in newer releases.
    >
    > > I don't know whether it just displays the number, or whether it
    > > determines anything based on it.
    > >
    > > Or what else might parse the version number?
    > >
    > > What if some proprietary userspace software like Skype or Flash or
    > > whatever parses the kernel version number at runtime and barfs on
    > > 2009.2.3 in a way similar to the OpenSSL build system?
    > >
    > > WHAT YOU SUGGEST WILL BREAK EXISTING USERSPACE SOFTWARE.
    > >
    > > Please admit this fact.

    >
    > "Might" I will give you, "Will", I will not without actually testing.


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

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

    > 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.

    The implementation might be trivial, but choosing between breaking
    existing userspace and breaking longexisting and standardized UNIX
    behavior is not a nice choice.

    > And to get back to the original point, Linus had expressed such an
    > interest in changing this a while ago, so I was bringing it up, saying
    > that I to thought we should change this, and proposed one such naming
    > change.


    Was he aware of the consequences?

    >...
    > thanks,
    >
    > greg "take a chill pill" k-h


    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/

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

    On Fri, Oct 17, 2008 at 9:53 AM, Dave Young wrote:
    >
    > Additionally, we can add some range to x.y.z
    >
    > such as:
    >
    > x: 1-9
    > y: 1-9
    > z: 1-30
    >
    > so we can jumo to 2.7.1 after 2.6.30
    >


    Then people will think 2.7.x is a development version like 2.5.x ...
    --
    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 Fri, Oct 17, 2008 at 5:05 PM, Jike Song wrote:
    > On Fri, Oct 17, 2008 at 9:53 AM, Dave Young wrote:
    >>
    >> Additionally, we can add some range to x.y.z
    >>
    >> such as:
    >>
    >> x: 1-9
    >> y: 1-9
    >> z: 1-30
    >>
    >> so we can jumo to 2.7.1 after 2.6.30
    >>

    >
    > Then people will think 2.7.x is a development version like 2.5.x ...


    But it isn't. I think it doesn't matter.

    There's no such development version now. It's just a chance to let
    every one know the old change.

    --
    Regards
    dave
    --
    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

    > So I proposed an alternative, YEAR.NUMBER. The year is easy to keep

    Which calendaring system ?

    Alan
    --
    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 Fri, 2008-10-17 at 11:56 +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.


    We have a uts namespace, you can make the thing return whatever well you
    please.



    --
    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 Fri, Oct 17, 2008 at 12:06:30PM +0200, Peter Zijlstra wrote:
    > On Fri, 2008-10-17 at 11:56 +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.

    >
    > We have a uts namespace, you can make the thing return whatever well you
    > please.


    Hostname, domainname, what else?
    --
    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 2 of 6 FirstFirst 1 2 3 4 ... LastLast