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?
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?
Let the bike-shedding begin!
thanks,
greg k-h
Greg KH wrote:
>
> 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?
>
> Let the bike-shedding begin!
>
Personally I find that having a simple counter is kind of nice, simply
because one can talk about 27, 28, 29, ... and actually be able to rely
on it being stable.
The 2.6 prefix has clearly outlived its utility. The easiest way to
deal with that is of course to simply drop it, but perhaps the best
thing to do would be to bump the major number to 3, and start out with
3.0 instead of 2.6.28, 3.1 for 2.6.29 and so on. This has the advantage
that we still retain the major number for "huge changes".
On the other hand, a number of projects have gone to simple counters for
version numbers, without a leading major. Just having *one* number (or
two for point releases) compensates to a large degree for the numbers
being large. Given that, we could just make it version 3 instead of
2.6.28, 4 instead of 2.6.29 and so on.
-hpa
On Wednesday 15 October 2008 09:03:37 pm H. Peter Anvin wrote:
> Greg KH wrote:
> > 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.
> >
> Personally I find that having a simple counter is kind of nice, simply
> because one can talk about 27, 28, 29, ... and actually be able to rely
> on it being stable.
How about 2008.27.0, 2008.27.1, 2008.28.0, ...
David
That would seem to combine the worst of both...
--
Sent from my mobile phone (pardon any lack of formatting)
-----Original Message-----
From: David Sanders <[email protected]>
Sent: Wednesday, October 15, 2008 18:51
To: H. Peter Anvin <[email protected]>
Cc: Greg KH <[email protected]>; Linus Torvalds <[email protected]>; [email protected]
Subject: Re: [RFC] Kernel version numbering scheme change
On Wednesday 15 October 2008 09:03:37 pm H. Peter Anvin wrote:
> Greg KH wrote:
> > 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.
> >
> Personally I find that having a simple counter is kind of nice, simply
> because one can talk about 27, 28, 29, ... and actually be able to rely
> on it being stable.
How about 2008.27.0, 2008.27.1, 2008.28.0, ...
David
On Wed, Oct 15, 2008 at 06:03:37PM -0700, H. Peter Anvin wrote:
> Greg KH wrote:
>> 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?
>> Let the bike-shedding begin!
>
> Personally I find that having a simple counter is kind of nice, simply
> because one can talk about 27, 28, 29, ... and actually be able to rely on
> it being stable.
I would love to do that, start with 28.0 and go from there.
It's just a number, might as well just treat it as such :)
thanks,
greg k-h
On 16.10.2008 02:25, Greg KH wrote:
> 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?
>
> 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
> [...]
That afaics has one minor downside: You don't know in advance how the
next kernel is going to be called. Example: the kernel that is currently
developed could become 2008.4 (the fifth kernel in 2008) if this
development cycle in the end is one of the quicker ones and gets
finished this year. But if everything is a bit slower then it might
become 2009.0 (the first one in 2009).
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...
> [...] Let the bike-shedding begin!
Please paint a tux on top of the roof.
CU
thl
--
Thorsten Leemhuis
c't- Magazin für Computertechnik web http://www.heise.de/ct/
Heise Zeitschriften Verlag GmbH&Co.KG phone +49 (0)511 5352 300
Helstorfer Str. 7 icq 140593172
D-30625 Hannover, Germany jabber [email protected]
/* Heise Zeitschriften Verlag GmbH & Co. KG, Registergericht:
Amtsgericht Hannover HRA 26709; Persönlich haftende Gesellschafterin:
Heise Zeitschriften Verlag Geschäftsführung GmbH, Registergericht:
Amtsgericht Hannover, HRB 60405 Geschäftsführer: Ansgar Heise,
Steven P. Steinkraus, Dr. Alfons Schräder */
On Thu, 16 Oct 2008, Thorsten Leemhuis wrote:
> On 16.10.2008 02:25, Greg KH wrote:
>> 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?
>>
>> 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
>> [...]
>
> That afaics has one minor downside: You don't know in advance how the next
> kernel is going to be called. Example: the kernel that is currently developed
> could become 2008.4 (the fifth kernel in 2008) if this development cycle in
> the end is one of the quicker ones and gets finished this year. But if
> everything is a bit slower then it might become 2009.0 (the first one in
> 2009).
>
> 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
either based on when the merge window opens, or when it's expected to be
released (and accept that you may have a 2008.3 released in early 2009, or
a 2009.1 released in december 2008)
David Lang
Greg KH <greg <at> kroah.com> writes:
>
> 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?
>
> We number the kernel based on the year, and the numbers of releases we
> have done this year:
> YEAR.NUMBER.MINOR_RELEASE
>
I strongly disagree about the full year indication in front ;)
and bring up my older idea of
the scheme to be s.yy.ww.tt, that is :
s - series, as it is now (freedom to Linus to declare a whole 'new generation'
;) if he wanted )
yy - two (in a hundred years, three) digits of the year
Now the interesting part begins which is
ww - the number of the week of the release. This will be between 1 and 52 (53)
tt - the number of the week of stable release. As above.
It is:
- most similar to the scheme used so far,
- informative : the ww and tt numbers are the week numbers of when the actual
release HAPPENED, not when it is predicted.
- easy to put some automation into it (git release HEAD now ) could branch the
current and rename it accordingly (not that I know how to do it, just
imagination)
- (mod) in case there are more than one release in a week, letters could be
used (e.g. 2.08.44[a..z]) in as many count as needed (2.08.45deadbeef.50sodead
)(or put the git commit indication there ?)
- in case the stable releases go forth into next year or over, the stable team
puts additional .yy.ww instead of their own .tt (like 2.08.45.09.05) (yes I know
it is long)
- the -rc releases go as usual beginning with latest mainline release
(2.08.45-rcX, X being a number as it is now)
- dubbing behavior of silicon manufacturers who print the actual week number of
production onto their chips - imagine looking at a chip and quick glancing at
the kernel version number and _knowing_ it should be OK ;)
My £0.02 ;)
>
> Any thoughts?
>
> Let the bike-shedding begin!
>
> thanks,
>
> greg k-h
>
Lukasz
el es wrote:
>
> the scheme to be s.yy.ww.tt, that is :
>
> s - series, as it is now (freedom to Linus to declare a whole 'new generation'
>
> ;) if he wanted )
>
> yy - two (in a hundred years, three) digits of the year
>
> Now the interesting part begins which is
>
> ww - the number of the week of the release. This will be between 1 and 52 (53)
>
> tt - the number of the week of stable release. As above.
>
> It is:
> - most similar to the scheme used so far,
> - 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.
-hpa
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.
Hans
H. Peter Anvin <hpa <at> 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.
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.
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.
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
el es <el_es_cr <at> yahoo.co.uk> writes:
>
> H. Peter Anvin <hpa <at> 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' ?
Oh, I just read your suggestion to move on with 3, 4 and so on. To keep it
simple.
How about adopting your scheme (simple counter) with mine (yy.ww.tt) ?
Speaking on my own, I think that some indication of WHEN the release actually
happened, encoded in the version number, IS desirable. I'm not a developer (my
field is far, far away) but personally I find the suggestions to put full year
figure in front, grossly disturbing everything we accustomed to ;)
OR.
If in my idea, we drop the .tt bit, hence, we declare, that the stable team just
continues the work on the released version, like
- 2.08.41 is the currently released 2.6.27,
- developers continue on 2.08.41-rcX, which gets promoted to 3.yy.ww when
released and so on,
- meanwhile the stable team releases 2.08.[42..52], 2.09.[01..52] and so on.
Being an indication of continuity.
As well as a revolution too ;)
> >
>
> Lukasz
>
>
Please don't use time indications inside kernel versions, it just gets confusing
(even more so if you use yy mm dd).
On Thu, 16 Oct 2008 10:05:32 +0000 (UTC)
el es <[email protected]> wrote:
> el es <el_es_cr <at> yahoo.co.uk> writes:
>
> >
> > H. Peter Anvin <hpa <at> 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' ?
>
> Oh, I just read your suggestion to move on with 3, 4 and so on. To keep it
> simple.
>
> How about adopting your scheme (simple counter) with mine (yy.ww.tt) ?
>
> Speaking on my own, I think that some indication of WHEN the release actually
> happened, encoded in the version number, IS desirable. I'm not a developer (my
> field is far, far away) but personally I find the suggestions to put full year
> figure in front, grossly disturbing everything we accustomed to ;)
>
> OR.
> If in my idea, we drop the .tt bit, hence, we declare, that the stable team just
> continues the work on the released version, like
>
> - 2.08.41 is the currently released 2.6.27,
> - developers continue on 2.08.41-rcX, which gets promoted to 3.yy.ww when
> released and so on,
> - meanwhile the stable team releases 2.08.[42..52], 2.09.[01..52] and so on.
>
> Being an indication of continuity.
> As well as a revolution too ;)
> > >
> >
> > Lukasz
> >
> >
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Kristoffer Ericson <[email protected]>
On Wed, Oct 15, 2008 at 05:25:09PM -0700, Greg KH wrote:
> Hi,
Hi Greg,
>...
> 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?
>...
how much of userspace breaks when we suddenly "just for fun" change the
version numbering scheme in a very radical way?
I'm not thinking of scripts for building the kernel.
I'm thinking of the fact that starting with glibc different pieces of
userspace software interpret the kernel version number they get from
various sources like e.g. <linux/version.h>, "uname -r" or an ioctl.
As a random example, the "config" script of OpenSSL 0.9.8g contains the
following:
<-- snip -->
...
RELEASE=`(uname -r) 2>/dev/null` || RELEASE="unknown"
...
case "${SYSTEM}:${RELEASE}:${VERSION}:${MACHINE}" in
...
Linux:[2-9].*)
echo "${MACHINE}-whatever-linux2"; exit 0
;;
Linux:1.*)
echo "${MACHINE}-whatever-linux1"; exit 0
;;
...
<-- snip -->
Change the version number of the kernel in the way you suggest, and
trying to build it will fail with:
<-- snip -->
$ ./config
Operating system: x86_64-whatever-Linux
This system (Linux) is not supported. See file INSTALL for details.
$
<-- snip -->
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...
> 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
* Greg KH <[email protected]> wrote:
> 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?
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.
Just my heretic 2 cents,
S.
PS: Nice timing, thunderstorm approaching.
--
In Russia, President kills Financial Crisis
On Wed, 15 Oct 2008, Greg KH wrote:
> 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?
> Any thoughts?
>
> Let the bike-shedding begin!
What about just using the git SHA1?
Advantages:
- We're all getting older. Training our memory to remember SHA1 IDs is
actually good for us!
- Perhaps Google will finally start tracking git commits, so I can
feed them a git commit ID mentioned in a random email and find the
actual commit, without having to know to which repository it
belongs?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Thu, 16 Oct 2008, 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.
If you want to leapfrog Microsoft (and perhaps want to bring a tribute
to UNIX at the same time?), just call the next version Linux 7.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Thu, Oct 16, 2008 at 03:49:43PM +0300, Adrian Bunk wrote:
> On Wed, Oct 15, 2008 at 05:25:09PM -0700, Greg KH wrote:
> > Hi,
>
> Hi Greg,
>
> >...
> > 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?
> >...
>
> how much of userspace breaks when we suddenly "just for fun" change the
> version numbering scheme in a very radical way?
>
> I'm not thinking of scripts for building the kernel.
>
> I'm thinking of the fact that starting with glibc different pieces of
> userspace software interpret the kernel version number they get from
> various sources like e.g. <linux/version.h>, "uname -r" or an ioctl.
>
> As a random example, the "config" script of OpenSSL 0.9.8g contains the
> following:
>
> <-- snip -->
>
> ...
> RELEASE=`(uname -r) 2>/dev/null` || RELEASE="unknown"
> ...
> case "${SYSTEM}:${RELEASE}:${VERSION}:${MACHINE}" in
> ...
> Linux:[2-9].*)
> echo "${MACHINE}-whatever-linux2"; exit 0
> ;;
>
> Linux:1.*)
> echo "${MACHINE}-whatever-linux1"; exit 0
> ;;
> ...
>
> <-- snip -->
>
>
> Change the version number of the kernel in the way you suggest, and
> trying to build it will fail with:
>
> <-- snip -->
>
> $ ./config
> Operating system: x86_64-whatever-Linux
> This system (Linux) is not supported. See file INSTALL for details.
> $
>
> <-- snip -->
>
>
> 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.
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 :)
thanks,
greg k-h
Greg KH ([email protected]) 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?
Bill
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.
- Ted
On Thu, Oct 16, 2008 at 11:30:53AM -0400, Bill Nottingham wrote:
> Greg KH ([email protected]) 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.
thanks,
greg k-h
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
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 ([email protected]) 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
On Thu, 16 Oct 2008, el es wrote:
> H. Peter Anvin <hpa <at> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>>>>> "Theodore" == Theodore Tso <[email protected]> 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
Theodore Tso <[email protected]> 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.
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
On Thu, Oct 16, 2008 at 11:35 PM, Theodore Tso <[email protected]> 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
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
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
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
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
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
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
On Fri, Oct 17, 2008 at 12:55 AM, Greg KH <[email protected]> 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
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
On Fri, Oct 17, 2008 at 9:53 AM, Dave Young <[email protected]> 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 ...
On Fri, Oct 17, 2008 at 5:05 PM, Jike Song <[email protected]> wrote:
> On Fri, Oct 17, 2008 at 9:53 AM, Dave Young <[email protected]> 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
> So I proposed an alternative, YEAR.NUMBER. The year is easy to keep
Which calendaring system ?
Alan
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.
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?
On Fri, 2008-10-17 at 15:18 +0400, Alexey Dobriyan wrote:
> 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?
Can't it fake the version number? - sounds like a useful feature :-)
On Fri, Oct 17, 2008 at 01:26:27PM +0200, Peter Zijlstra wrote:
> On Fri, 2008-10-17 at 15:18 +0400, Alexey Dobriyan wrote:
> > 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?
>
> Can't it fake the version number? -
It can, but is there a system call for this?
> sounds like a useful feature :-)
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 ?
- a stable version in January of a kernel released in December
still has the old year? (I hope yes, but it could confuse users.)
- when (if) we need a big innovative (or incompatible) kernel
change, how to mark old and new kernels?
ciao
cate
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"?
I imagine many embedded products regularly build (or even cross-build) a
kernel and a matching userspace against that kernel, independent of the
running kernel on the build machine. I know that we do it every day...
Chris
Alan Cox wrote:
>> So I proposed an alternative, YEAR.NUMBER. The year is easy to keep
>
> Which calendaring system ?
Presumably the Gregorian one, rooted in the Common Era, but that's sort
of irrelevant.
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.
-hpa
On Fri, Oct 17, 2008 at 02:46:27PM +0200, 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 ?
Sure, what's the big deal?
> - a stable version in January of a kernel released in December
> still has the old year? (I hope yes, but it could confuse users.)
stable versions would not modify the year.
> - when (if) we need a big innovative (or incompatible) kernel
> change, how to mark old and new kernels?
Based on our current development model, this isn't an issue.
thanks,
greg k-h
On Fri, Oct 17, 2008 at 09:40:32AM -0700, H. Peter Anvin wrote:
> Alan Cox wrote:
>>> So I proposed an alternative, YEAR.NUMBER. The year is easy to keep
>> Which calendaring system ?
>
> Presumably the Gregorian one, rooted in the Common Era, but that's sort of
> irrelevant.
>
> 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?
thanks,
greg k-h
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.
Great, then why does the build system depend on the running kernel?
Doesn't that sound like a bug?
> > > > 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.
Again, depending on the kernel the product is being built on, to
determine a build-time configuration, seems quite broken if you want to
do cross-compilation.
Or you just do native builds, on the kernel you expect to run the
product, and everyone is happy and there are no errors.
thanks,
greg k-h
On Fri, Oct 17, 2008 at 10:31:38AM +0100, Alan Cox wrote:
> > So I proposed an alternative, YEAR.NUMBER. The year is easy to keep
>
> Which calendaring system ?
I'm almost afraid to ask, but "which one would you prefer"? :)
thanks,
greg k-h
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.
That would be trivial for me to test, IFF we want to do something like
this.
But again, that's a technical thing, that can be solved _IFF_ we want to
change things.
And that's my point here, do we want to change the current numbering
scheme as people have expressed annoyances of the current one.
thanks,
greg k-h
On Friday 17 October 2008, Greg KH wrote:
> 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.
>
> That would be trivial for me to test, IFF we want to do something like
> this.
>
> But again, that's a technical thing, that can be solved _IFF_ we want to
> change things.
>
> And that's my point here, do we want to change the current numbering
> scheme as people have expressed annoyances of the current one.
Numbering scheme? I thought we should all be using the official
kernel version NAME after the -final release? Was I mistaken?
PS1 seems like somebody forgot to update it for 2.6.27...
PS2 current numbering scheme is OK
Thanks,
Bart
On Fri, 17 Oct 2008 10:41:27 -0700
Greg KH <[email protected]> wrote:
> On Fri, Oct 17, 2008 at 10:31:38AM +0100, Alan Cox wrote:
> > > So I proposed an alternative, YEAR.NUMBER. The year is easy to keep
> >
> > Which calendaring system ?
>
> I'm almost afraid to ask, but "which one would you prefer"? :)
The standard one shipped and supported by util-linux for the past 15 or
more years
$ ddate
Today is Setting Orange, the 71st day of Bureaucracy in the YOLD 3174
> 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 ...
(Ducks)
Alan
On Fri, Oct 17, 2008 at 08:45:06PM +0100, Alan Cox wrote:
> On Fri, 17 Oct 2008 10:41:27 -0700
> Greg KH <[email protected]> wrote:
>
> > On Fri, Oct 17, 2008 at 10:31:38AM +0100, Alan Cox wrote:
> > > > So I proposed an alternative, YEAR.NUMBER. The year is easy to keep
> > >
> > > Which calendaring system ?
> >
> > I'm almost afraid to ask, but "which one would you prefer"? :)
>
> The standard one shipped and supported by util-linux for the past 15 or
> more years
>
> $ ddate
> Today is Setting Orange, the 71st day of Bureaucracy in the YOLD 3174
Fine with me :)
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.
thanks,
greg k-h
On Fri, Oct 17, 2008 at 09:06:28PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Friday 17 October 2008, Greg KH wrote:
> > 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.
> >
> > That would be trivial for me to test, IFF we want to do something like
> > this.
> >
> > But again, that's a technical thing, that can be solved _IFF_ we want to
> > change things.
> >
> > And that's my point here, do we want to change the current numbering
> > scheme as people have expressed annoyances of the current one.
>
> Numbering scheme? I thought we should all be using the official
> kernel version NAME after the -final release? Was I mistaken?
>
> PS1 seems like somebody forgot to update it for 2.6.27...
Cool, that means I get to do it :)
thanks,
greg k-h
On 17.10.2008 14:44, 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.
Personally i could live without the 4 part numbers of the stable series.
When you bump down the third position to second, then fill the third one
with a dummy/fixed for the "Linus" release, the way is free for stable
releases that don't feel so stapled to the side.
So with either .0 or .1 for the "Linus" release the next kernel could be:
2.8.0 or 2.8.1
(I would skip 2.7, because it is still perceived as the next development
Version.)
The stable releases then increment the third number and the next Linus
release could be 2.9.x because i don't think after 2.8 any skipping of
uneven numbers would be needed anymore.
In Short: "Back to the roots" with a "good old" 3 part version numbers,
with stable releases "build into the numbering scheme" instead of
stapled to the side.
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
On Friday, 17 of October 2008, 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 :)
Surely some scripts will start to break as soon as the third number gets
three digits.
> 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.
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.
This seems to be close enough to the current numbering so that nothing should
really break.
Thanks,
Rafael
On Fri, 17 Oct 2008, 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.
things that do this sort of check would work just find with version 8.10.0
or 2008.10.0
the ones that would fail would be ones that made assumptions about the
number (it can only have X digits in this position, I don't need to check
the '2', only the '4' vs '6', etc). anything that does this sort of thing
is broken already, and will fail at some point in the future, even without
a radical numbering change.
> 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 suspect that you won't see anything noticable. you don't need to make a
branch of the kernel, just edit the kernel source to change the version.
> 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.
one nice thing about the year-based numbering (be it 8.x or 2008.x) is
that all the numbers in the new numbering scheme are > any numbers in the
old numbering scheme. so all you need to do is to check for > whatever
version added the feature you need.
> 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.
Red Herring, the Cool New Stuff is happening now, no 2.7 needed.
David Lang
On Sat, 18 Oct 2008, Rafael J. Wysocki wrote:
> On Friday, 17 of October 2008, 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 :)
>
> 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)
>> 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.
>
> 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.
David Lang
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
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
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.
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: [email protected]
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
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
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
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
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
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 bullshit:
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
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 bullshit:
>
> 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
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 bullshit:
> >
> > 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
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
On Thursday 2008-10-16 03:34, [email protected] 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.
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.
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.
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.
On Fri, 17 Oct 2008, [email protected] 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
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
On Sun, 19 Oct 2008, Jiri Kosina wrote:
> On Fri, 17 Oct 2008, [email protected] 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
On Sat, 18 Oct 2008, Jan Engelhardt wrote:
> On Thursday 2008-10-16 03:34, [email protected] 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.
huh?
we are picking the name for the next kernel far more in advance today (we
know that the next kernel will be named 2.6.28, and the one after thta
2.6.29)
I'm just saying, pick the name/number for the kernel based on when the
merge window opened.
if it's the first merge window in 2009 the kernel would be 2009.1.0, if
it's the 5th merge window it would be 2009.5.0, even if the resulting
kernel ended up getting released in 2010
David Lang
On Saturday 2008-10-18 21:52, [email protected] wrote:
>> >
>> > pick a name when the merge window opens
>>
>> Hell no, we're not a distro.
>
> huh?
>
> we are picking the name for the next kernel far more in advance today (we know
> that the next kernel will be named 2.6.28, and the one after thta 2.6.29)
"name" is not the same as "version". When you say name, I get this:
$ grep NAME Makefile
NAME = Rotary Wombat
and we, hey, we already have names!
> I'm just saying, pick the name/number for the kernel based on when the merge
> window opened.
Yeah. I mean that's how it was done so far :)
On Sun, Oct 19, 2008 at 01:17:19AM +0200, Jiri Kosina wrote:
> 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?
It has nothing to do with age, but with the number of digits. Having 4 series
of digits is not easy, especially when some of them are two-digits large.
2.6.26.25-rc1 and 2.6.25.26-rc1 are obviously confusing and not old (not
even released).
> 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?
Yes I probably would, and I already said I would not like such a numbering
which is even worse IMHO. I'm for small number of digits, X.Y[.Z] with both
X and Y < 10, and Z the stable release. In 22 years, X will go to 10 which
is still not a problem.
> Or how would you distingiush the kernel tree you are maintaing from the
> one Linus is maintaining?
Another reason why I don't like dates. It makes forked versions more
confusing. Assuming that in 10 years we get 40 versions further, we
might be at version 6.8 and maybe I would have switched to maintain
"old" version 4.2. There is no confusion here.
BTW, speaking about dates, I noticed that others have experimented
with dates and finally changed their mind. Even microsoft. Remember
windows 3.1/3.11 ? In parallel, you had NT 3.5. After that you got
windows 95 (year of predicted release), then 98 (idem). In parallel,
NT went to 4.0. Then they merged all of them into windows 2000,
dropping the versions. Then they started inventing stupid names
like ME, Xp, Vista, ... and now they're talking about windows 7,
which should take its version from the kernel, because the kernel
has kept being versionned "normally" (no marketting involved in
this area). So they might have noticed that using years makes the
whole thing more complex for everyone in the long term. They get
laughed at when releases are delayed, people don't really know if
their seemingly old "2003" is really old or the last one, etc...
Probably that using dates in packaged products such as distros
based on whatever is available at the given date and meant to
evolve quickly and not being supported for long is good however.
It's just a snapshot at a given date and nothing more.
Willy
On Sunday, 19 of October 2008, Jiri Kosina wrote:
> On Fri, 17 Oct 2008, [email protected] 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 :)
Hm, why would that happen?
Rafael
On Sun, 19 Oct 2008, Rafael J. Wysocki wrote:
> On Sunday, 19 of October 2008, Jiri Kosina wrote:
>> On Fri, 17 Oct 2008, [email protected] 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 :)
>
> Hm, why would that happen?
with the date based numbers, that was one of the things that 'could'
happen as the year changed (2008.5.0-rc4 would be followed by
2009.1.0-rc5)
David Lang
On Sunday, 19 of October 2008, [email protected] wrote:
> On Sun, 19 Oct 2008, Rafael J. Wysocki wrote:
>
> > On Sunday, 19 of October 2008, Jiri Kosina wrote:
> >> On Fri, 17 Oct 2008, [email protected] 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 :)
> >
> > Hm, why would that happen?
>
> with the date based numbers, that was one of the things that 'could'
> happen as the year changed (2008.5.0-rc4 would be followed by
> 2009.1.0-rc5)
Well, in that case I think it would be reasonable to cuntinue the 2008
numbering so that 2009.1.0-rc5 in your example would still be 2008.5.0-rc5.
That said, I kind of agree that the numbering need not be time-related. One
alternative might be to release 2.9.0 instead of 2.6.29 and then continue in
in such a way that each of the three numbers is always a one-digit decimal.
Then, we'd have 2.9.0, 2.9.1 ... 2.9.9, 3.0.0, 3.0.1 etc.
Thanks,
Rafael
On Sun, 19 Oct 2008, Rafael J. Wysocki wrote:
> On Sunday, 19 of October 2008, [email protected] wrote:
>> On Sun, 19 Oct 2008, Rafael J. Wysocki wrote:
>>
>>> On Sunday, 19 of October 2008, Jiri Kosina wrote:
>>>> On Fri, 17 Oct 2008, [email protected] 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 :)
>>>
>>> Hm, why would that happen?
>>
>> with the date based numbers, that was one of the things that 'could'
>> happen as the year changed (2008.5.0-rc4 would be followed by
>> 2009.1.0-rc5)
>
> Well, in that case I think it would be reasonable to cuntinue the 2008
> numbering so that 2009.1.0-rc5 in your example would still be 2008.5.0-rc5.
>
> That said, I kind of agree that the numbering need not be time-related. One
> alternative might be to release 2.9.0 instead of 2.6.29 and then continue in
> in such a way that each of the three numbers is always a one-digit decimal.
> Then, we'd have 2.9.0, 2.9.1 ... 2.9.9, 3.0.0, 3.0.1 etc.
so how would you do the -stable releases?
David Lang
On Sunday, 19 of October 2008, [email protected] wrote:
> On Sun, 19 Oct 2008, Rafael J. Wysocki wrote:
>
> > On Sunday, 19 of October 2008, [email protected] wrote:
> >> On Sun, 19 Oct 2008, Rafael J. Wysocki wrote:
> >>
> >>> On Sunday, 19 of October 2008, Jiri Kosina wrote:
> >>>> On Fri, 17 Oct 2008, [email protected] 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 :)
> >>>
> >>> Hm, why would that happen?
> >>
> >> with the date based numbers, that was one of the things that 'could'
> >> happen as the year changed (2008.5.0-rc4 would be followed by
> >> 2009.1.0-rc5)
> >
> > Well, in that case I think it would be reasonable to cuntinue the 2008
> > numbering so that 2009.1.0-rc5 in your example would still be 2008.5.0-rc5.
> >
> > That said, I kind of agree that the numbering need not be time-related. One
> > alternative might be to release 2.9.0 instead of 2.6.29 and then continue in
> > in such a way that each of the three numbers is always a one-digit decimal.
> > Then, we'd have 2.9.0, 2.9.1 ... 2.9.9, 3.0.0, 3.0.1 etc.
>
> so how would you do the -stable releases?
In the same way as they are done now, ie. 2.9.0.1, 2.9.0.2 etc. I don't think
there's any problem with having 2.9.1.33 for example. ;-)
Thanks,
Rafael
On Sat, Oct 18, 2008 at 06:33:52PM -0400, Jan Engelhardt wrote:
>
> 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.
Huh? I'm showing discontent here. Is that not "real"?
thanks,
greg k-h
On Sunday 2008-10-19 14:33, Greg KH wrote:
>>
>> If there is a real discontent about the version
>> number it would have already been changed.
^{on Linus's side}
>> Given that nothing happened, it seems it is tolerated.
>
>Huh? I'm showing discontent here. Is that not "real"?
On Sun, 19 Oct 2008, Jan Engelhardt wrote:
> On Sunday 2008-10-19 14:33, Greg KH wrote:
>>>
>>> If there is a real discontent about the version
>>> number it would have already been changed.
> ^{on Linus's side}
>>> Given that nothing happened, it seems it is tolerated.
he is the one who raised the subject, so there is discontent. Linus asked
the question of what to move to.
David Lang
On Oct 18, 2008, "H. Peter Anvin" <[email protected]> wrote:
> Greg KH wrote:
>> 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.
Just do like car manufacturers. When it's 2008, you can already shop
around their 2009 models. Linux could do the same. We could right
now decide that 2.6.29 is going to be 2009.1 (or 9.1, or 2.9.1,
whatever), and then, even if it's still 2008 when it goes out, so
what?
(The 2.6.28 cycle has already started, so it's probably easier to just
leave it alone)
> 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.
+1
Not that I care one way or the other. It's just that I don't see how
your response bears any relationship with the point Greg made. It's
just a distraction. We're talking about how to label releases, not
about guessing the release date of a kernel months ahead. One you
label it, it stays that way.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
On Thursday 16 October 2008 08:35, Theodore Tso wrote:
> Let's just leave things the way they are.
Or drop the useless fourth number and resume incrementing the minor
number if not the major.
Or just leave things the way they are, indeed. I see Linus has
managed a prodigious silence on the troll, err, subject and with luck
it will stay that way.
Regards,
Daniel
Alexandre Oliva wrote:
>
>> 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.
>
> +1
>
> Not that I care one way or the other. It's just that I don't see how
> your response bears any relationship with the point Greg made. It's
> just a distraction. We're talking about how to label releases, not
> about guessing the release date of a kernel months ahead. One you
> label it, it stays that way.
>
Uhm, so what happens when a release starts with an -rc stage intended
for 2008 release, and then comes out in 2009? You either have to leave
it at 2008, which would be confusing (I think this is what M$ did in at
least one case), or you have to have an in-release-cycle change.
Plus, of course, it makes it hard to talk about future releases.
-hpa
Let me post my stupid idea :-) Dont hit me :-)
releasenum.branch.subreleasename(chars)+subreleasenumber(numbers).deepersubreleasename.....
1.vanilla.pre3
1.vanilla.rc1
1.vanilla.0 (stable release)
1.vanilla.fix1 (first stable patch)
2.mm.rc5
2.netdev.git2342424323423423
current versions, let's start from 2.6.27 looks like
2627.vanilla.0
next will be 2628
It is easy to parse, easy to find out what is a "base" release number, for
patches and other trees
for mm's, for example, based on unstable kernels
mm.2.rc5.mm2
easy to understand, that it is mm branch, based on stable release 2, release
candidate 5, mm patchset N2
Since Linus told there is no need in 2.6, probably there is no reason to keep
even this numbers.
On Oct 20, 2008, "H. Peter Anvin" <[email protected]> wrote:
> Uhm, so what happens when a release starts with an -rc stage intended
> for 2008 release, and then comes out in 2009?
I see at least two possibilities:
- it stays 2008, as originally intended.
- it's labeled 2009 since the beginning of the release cycle
If it gets released in a year other than originally planned, it's no
more confusing that buying a 2009-series car in 2008, or Fiscal Years
vs Calendar Years.
Personally, I'd rather go with the second option than the first, if
nothing else because people seem to like better next year's stuff than
last year's stuff. But it's not like it matters much. The point
(AFAICT) is to give some rough guidance of the time-frame of the
release, not something like $(date +%s) of the beginning or end of the
release cycle.
Major might as well be defined as Year+/-1 - Constant, monotonically
increasing. This should work and make sense as long as no release
cycle takes longer than say a year or two.
> Plus, of course, it makes it hard to talk about future releases.
Not that it makes a lot of sense to talk about future releases other
than the next two or so, but we could right now agree to use the
following replacement table. Does your roadmap cover longer than
that? Did I get the release year approximations wrong?
2.6.28 doesn't change
2.6.29 <-> 2009.1
2.6.30 <-> 2009.2
2.6.31 <-> 2009.3
2.6.32 <-> 2010.1
2.6.33 <-> 2010.2
2.6.34 <-> 2010.3
2.6.35 <-> 2010.4
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Alexandre Oliva wrote:
> Not that I care one way or the other. It's just that I don't see how
> your response bears any relationship with the point Greg made. It's
> just a distraction. We're talking about how to label releases, not
> about guessing the release date of a kernel months ahead. One you
> label it, it stays that way.
Greg,
I do agree with you that kernel numbering is becoming increasingly
cumbersome now the numbers are becoming larger, and a spreadsheet is
becoming a handy tool for tracking all this release information.
I'm honestly not sold on any of the naming schemes proposed thusfar, but
since I can't come up with a magic solution, I'll shut up about that!
What I'd love to see any changes integrate would be a simple way to spot
-stable releases in the version number (ie: 2.6.16, 2.6.27, those
maintained for a "long" time and hopefully by 2.6.16.50+ quite 'bug
free') versus the rest of releases sent out on a more regular basis.
I'll immediately concede this is probably of minimal benefit to
distribution maintainers who're actively following LKML and development
in general, but there is a big community of folks out there using
vanilla kernel.org sources for their own needs who, like me, probably
find it difficult/frustrating to pick a kernel version these days.
Does anyone have a suggestion how that could be accomplished?
Alex
On Sat, Oct 18, 2008 at 10:45:05AM +0200, Willy Tarreau wrote:
> 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.
Yeah, I'm not the only one that has done that then :)
And yes, it is a pain to fix up.
> 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.
I agree that would be nicer, and easier for everyone.
thanks,
greg k-h
On Mon, Oct 20, 2008 at 07:55:29PM +0100, Alex Howells wrote:
> Alexandre Oliva wrote:
>> Not that I care one way or the other. It's just that I don't see how
>> your response bears any relationship with the point Greg made. It's
>> just a distraction. We're talking about how to label releases, not
>> about guessing the release date of a kernel months ahead. One you
>> label it, it stays that way.
>
> Greg,
>
> I do agree with you that kernel numbering is becoming increasingly
> cumbersome now the numbers are becoming larger, and a spreadsheet is
> becoming a handy tool for tracking all this release information.
>
> I'm honestly not sold on any of the naming schemes proposed thusfar, but
> since I can't come up with a magic solution, I'll shut up about that!
>
> What I'd love to see any changes integrate would be a simple way to spot
> -stable releases in the version number (ie: 2.6.16, 2.6.27, those
> maintained for a "long" time and hopefully by 2.6.16.50+ quite 'bug free')
> versus the rest of releases sent out on a more regular basis.
What do you mean? The .y marking of releases right now doesn't show you
this?
The "longevity" of a release series has no real correlation to it's "bug
free"ness of it in any strict sense of the word. Just look at the
percentage of fixes in any normal release for "bugs" to get a concrete
feel for that (hint, it's in the thousands).
> I'll immediately concede this is probably of minimal benefit to
> distribution maintainers who're actively following LKML and development in
> general, but there is a big community of folks out there using vanilla
> kernel.org sources for their own needs who, like me, probably find it
> difficult/frustrating to pick a kernel version these days.
What is frustrating about it right now? It is _strongly_ recommended
that if you are following the kernel.org tree, for you to rely on the
-stable releases. It is best if you can upgrade to the latest branch of
the stable releases when they come out, moving to the latest major
release when possible, as you usually only have a month or so when they
start up before the previous branch's stable tree stops being
maintained.
Some times I think I need to put up a big .SVG drawing of all of the
releases, showing which ones are currently being maintained, and which
ones aren't just to make it easier. I wonder if firefox could show it
properly, would that help out?
thanks,
greg k-h
On Mon, Oct 20, 2008 at 01:30:33PM -0700, Greg KH wrote:
> > 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.
>
> I agree that would be nicer, and easier for everyone.
It's true it would be easier for tracking down and remembering the
version number, but on the other hand, the good thing about this
version number system is that we now 2.6.xx is a rather stable and
complete kernel tree and when we move to 2.7, we know it'll be the start
for the 2.8 kernel series.
Just like the migration from 2.4 to 2.5.
Also, changing now the version numbering would be troublesome as well.
Most of the users/developers who tracks linux-2.6.git are used to
have 3 levels of version number.
Still, it's nice to start thinking about it now since we're getting
closer to last sublevel of 2.4 series (i think it was 2.4.37 ??) and try
to find a new scheme for version numbering before thinking about 2.7 (or
3.0 ??) series.
--
balbi
On Mon, Oct 20, 2008 at 11:54:00PM +0300, Felipe Balbi wrote:
> On Mon, Oct 20, 2008 at 01:30:33PM -0700, Greg KH wrote:
> > > 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.
> >
> > I agree that would be nicer, and easier for everyone.
>
> It's true it would be easier for tracking down and remembering the
> version number, but on the other hand, the good thing about this
> version number system is that we now 2.6.xx is a rather stable and
> complete kernel tree and when we move to 2.7, we know it'll be the start
> for the 2.8 kernel series.
Um, did you not get the memo 3 years ago saying we are changing our
development model and there will not be a 2.7 development series?
Damm, I thought I had printed it out and placed it on everyone's chairs.
Those pesky cleaners must have picked it up and recycled it, sorry about
that...
> Just like the migration from 2.4 to 2.5.
Please don't bring up the dark ages again, many of us went through
things back then that have taken a lot of counseling to be able to get
over.
thanks,
greg k-h
On Monday 20 October 2008, Greg KH wrote:
> Um, did you not get the memo 3 years ago saying we are changing our
> development model and there will not be a 2.7 development series?
Well, in theory we could resume the old numbering scheme again but
keep the current development model, in effect just inflating the
version numbers by one level:
2.6.28-rc1 -> 2.7.0
2.6.28-rc2 -> 2.7.1
2.6.28 -> 2.8.0 (perfect -- I've heard people informally call it
the two-eight release in the past instead of
two-six-twenty-eight)
2.6.28.1 -> 2.8.1
2.6.29-rc1 -> 2.9.0
2.6.29 -> 2.10.0 or 3.0.0 (depending on your taste)
This would be entirely consistent with how things have been since 1.0,
except that we have not had a 2.odd release in a long time.
Arnd <><
On Mon, Oct 20, 2008 at 02:06:48PM -0700, Greg KH wrote:
> On Mon, Oct 20, 2008 at 11:54:00PM +0300, Felipe Balbi wrote:
> > On Mon, Oct 20, 2008 at 01:30:33PM -0700, Greg KH wrote:
> > > > 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.
> > >
> > > I agree that would be nicer, and easier for everyone.
> >
> > It's true it would be easier for tracking down and remembering the
> > version number, but on the other hand, the good thing about this
> > version number system is that we now 2.6.xx is a rather stable and
> > complete kernel tree and when we move to 2.7, we know it'll be the start
> > for the 2.8 kernel series.
>
> Um, did you not get the memo 3 years ago saying we are changing our
> development model and there will not be a 2.7 development series?
>
> Damm, I thought I had printed it out and placed it on everyone's chairs.
> Those pesky cleaners must have picked it up and recycled it, sorry about
> that...
>
> > Just like the migration from 2.4 to 2.5.
>
> Please don't bring up the dark ages again, many of us went through
> things back then that have taken a lot of counseling to be able to get
> over.
sorry if i'm developing linux kernel for as long as you are. It's really
not my business how many hours of counseling you had to attend to get
over a version numbering change.
Maybe you still need a bit more, judging by your reply.
--
balbi
Alex Howells wrote:
> What I'd love to see any changes integrate would be a simple way to spot
> -stable releases in the version number (ie: 2.6.16, 2.6.27, those
> maintained for a "long" time and hopefully by 2.6.16.50+ quite 'bug
> free') versus the rest of releases sent out on a more regular basis.
Side note: Long-term maintained kernels like Adrian's 2.6.16.y or
distro kernels of this sort -> are not 'quite bug free' <-. They are
only -> quite regression free <-.
If you want bug fixes, you generally want new kernels. Only a fraction
of the bug fixes in new kernels are backported to the long-term
maintained stable kernels. OTOH, also only a fraction of the
regressions in new kernels is backported to them.
--
Stefan Richter
-=====-==--- =-=- =-=-=
http://arcgraph.de/sr/
Felipe Balbi wrote:
> On Mon, Oct 20, 2008 at 02:06:48PM -0700, Greg KH wrote:
>> On Mon, Oct 20, 2008 at 11:54:00PM +0300, Felipe Balbi wrote:
>>> when we move to 2.7, we know it'll be the start
>>> for the 2.8 kernel series.
>> Um, did you not get the memo 3 years ago saying we are changing our
>> development model and there will not be a 2.7 development series?
>>
>> Damm, I thought I had printed it out and placed it on everyone's chairs.
>> Those pesky cleaners must have picked it up and recycled it, sorry about
>> that...
>>
>>> Just like the migration from 2.4 to 2.5.
>> Please don't bring up the dark ages again, many of us went through
>> things back then that have taken a lot of counseling to be able to get
>> over.
>
> sorry if i'm developing linux kernel for as long as you are. It's really
> not my business how many hours of counseling you had to attend to get
> over a version numbering change.
The switch from 2.2/2.3/2.4/2.5 to 2.6.x was not a change of numbering
scheme, it was a change of the development model. 2.4 and 2.5 were two
parallel mainlines. 2.6.x is a single mainline, and there won't be two
mainlines again in any foreseeable future.
> Maybe you still need a bit more, judging by your reply.
Or maybe not. You obviously misread his post.
--
Stefan Richter
-=====-==--- =-=- =-=-=
http://arcgraph.de/sr/
On Tue, Oct 21, 2008 at 09:11:52PM +0200, ext Stefan Richter wrote:
> Felipe Balbi wrote:
>> On Mon, Oct 20, 2008 at 02:06:48PM -0700, Greg KH wrote:
>>> On Mon, Oct 20, 2008 at 11:54:00PM +0300, Felipe Balbi wrote:
>>>> when we move to 2.7, we know it'll be the start
>>>> for the 2.8 kernel series.
>>> Um, did you not get the memo 3 years ago saying we are changing our
>>> development model and there will not be a 2.7 development series?
>>>
>>> Damm, I thought I had printed it out and placed it on everyone's chairs.
>>> Those pesky cleaners must have picked it up and recycled it, sorry about
>>> that...
>>>
>>>> Just like the migration from 2.4 to 2.5.
>>> Please don't bring up the dark ages again, many of us went through
>>> things back then that have taken a lot of counseling to be able to get
>>> over.
>>
>> sorry if i'm developing linux kernel for as long as you are. It's really
>> not my business how many hours of counseling you had to attend to get
>> over a version numbering change.
>
> The switch from 2.2/2.3/2.4/2.5 to 2.6.x was not a change of numbering
> scheme, it was a change of the development model. 2.4 and 2.5 were two
> parallel mainlines. 2.6.x is a single mainline, and there won't be two
> mainlines again in any foreseeable future.
at least now you gave me the reasons and I got the point. Thanks for
clarifying.
--
balbi
Greg KH wrote:
> What do you mean? The .y marking of releases right now doesn't show you
> this?
Sorry, perhaps I wasn't clear with regards "bugs" vs. "regressions" as
someone else pointed out in a reply :)
> The "longevity" of a release series has no real correlation to it's "bug
> free"ness of it in any strict sense of the word. Just look at the
> percentage of fixes in any normal release for "bugs" to get a concrete
> feel for that (hint, it's in the thousands).
Okay, sure.
> What is frustrating about it right now? It is _strongly_ recommended
> that if you are following the kernel.org tree, for you to rely on the
> -stable releases. It is best if you can upgrade to the latest branch of
> the stable releases when they come out, moving to the latest major
> release when possible, as you usually only have a month or so when they
> start up before the previous branch's stable tree stops being
> maintained.
That was what I was inviting people to solve, actually.
What I don't think is 100% clear right now is which kernels are still
actively maintained, and which are not. When does a kernel become EoL?
This is different for things like 2.6.16.x and 2.6.27.x to others?
Perhaps this could be a part of the version numbering scheme?
I'm speaking only from personal experience here, but have had hideous
issues getting a "one kernel fits all" solution for boxes at work.
Requirements for me to put a kernel on a given server would be:
* supports the hardware
* no security holes [in options I enable]
* works reliably, under load/stress.
Now I wouldn't call myself an 'expert' by any means, so please forgive
me in advance if I'm wrong in any of the following...
A lot of the problems I've spotted have been traced (kind thanks to
Daniel Drake, Francois Romieu and others) to the network drivers,
particularly forcedeth/r8169 NICs actually but some e1000 stuff too.
Filing bugs and getting those issues fixed for everyone is important,
but sometimes the question remains "Why upgrade when 2.6.16.xx meets the
criteria above? Can we be sure 2.6.24.xx will be as stable?".
There is nothing stopping you setting aside a couple of boxes and
checking the latest -stable for testing purposes, for planning where you
*will* go when 2.6.16.xx stops being maintained, and filing any bugs you
spot along the way to try and contribute to this effort.
This mostly came about because we have a large-ish number of boxes
currently tracking 2.6.16.xx and that works *very* well for us.
Discovering that 2.6.16 would be maintained in such a way was tough
though as I'm only a fairly recent subscriber to LKML.
So with regards to supported kernels, the following springs to mind:
* how long is kernel 2.6.xx supported?
* is kernel 2.6.xx one of the "longer term" supported ones?
* what are the requirements for a maintainer to push a
new release, a la 2.6.xx.yy? Is it based on time elapsed,
severity of any fixes included?
* how do we define "support" in this context?
does it mean security problems discovered/fixed *after*
development focus has moved on to new stuff is backported?
does it mean [critical] bug fixes? regression fixes?
> Some times I think I need to put up a big .SVG drawing of all of the
> releases, showing which ones are currently being maintained, and which
> ones aren't just to make it easier. I wonder if firefox could show it
> properly, would that help out?
It would :) Thanks for your response.
Alex
On Tue, 21 Oct 2008 20:52:02 BST, Alex Howells said:
> Requirements for me to put a kernel on a given server would be:
> * supports the hardware
The problem is that "supports" is often a fuzzy jello-like substance you
try to nail to a tree. You mention the R8169 and e1000 drivers - if they
bring the device up, but have issues under corner cases, is that "supports"
or not?
> * no security holes [in options I enable]
Similarly for "no security holes". At *BEST*, you'll get "no *known* *major*
security holes", unless you feel like auditing the entire source tree. There's
a whole slew of bugs that we can't even agree if they *are* security bugs or
just plain bugs - see Linus's rant on the subject a few months back.
> * works reliably, under load/stress.
And you win the trifecta - I don't think we've *ever* shipped a Linux kernel
that worked reliably under the proper "beat on the scheduler/VM corner case"
load/stress testing. Again, the best you can hope for is "doesn't fall over
under non-pathological non-corner-case loads when sufficient resources are
available so the kernel has a fighting chance". Doing 'make -j100' on a
single Core2 Duo is gonna be painful, no matter what.
On Tue, 21 Oct 2008 20:41:24 -0400, you wrote:
>On Tue, 21 Oct 2008 20:52:02 BST, Alex Howells said:
>> Requirements for me to put a kernel on a given server would be:
>
>> * supports the hardware
>The problem is that "supports" is often a fuzzy jello-like substance you
>try to nail to a tree. You mention the R8169 and e1000 drivers - if they
>bring the device up, but have issues under corner cases, is that "supports"
>or not?
>
>> * no security holes [in options I enable]
>Similarly for "no security holes". At *BEST*, you'll get "no *known* *major*
>security holes", unless you feel like auditing the entire source tree. There's
>a whole slew of bugs that we can't even agree if they *are* security bugs or
>just plain bugs - see Linus's rant on the subject a few months back.
>
>> * works reliably, under load/stress.
>And you win the trifecta - I don't think we've *ever* shipped a Linux kernel
>that worked reliably under the proper "beat on the scheduler/VM corner case"
>load/stress testing. Again, the best you can hope for is "doesn't fall over
>under non-pathological non-corner-case loads when sufficient resources are
>available so the kernel has a fighting chance".
>... Doing 'make -j100' on a
>single Core2 Duo is gonna be painful, no matter what.
Not painful at all, make -j100 is four seconds faster than a make -j5 on
a Core2Duo here with slamd64-12.1 (real: 3m21 vs 3m21).
Grant.
--
http://bugsplatter.id.au
Hey Valdis
>> Requirements for me to put a kernel on a given server would be:
>
>> * supports the hardware
> The problem is that "supports" is often a fuzzy jello-like substance you
> try to nail to a tree. You mention the R8169 and e1000 drivers - if they
> bring the device up, but have issues under corner cases, is that "supports"
> or not?
Oh agreed, this is all very "use case" specific. I'm making all of the
following statements based on the specific hardware we use, and assuming
'stability' based on the kernel/hardware passing a number of tests.
>> * no security holes [in options I enable]
> Similarly for "no security holes". At *BEST*, you'll get "no *known* *major*
> security holes", unless you feel like auditing the entire source tree. There's
> a whole slew of bugs that we can't even agree if they *are* security bugs or
> just plain bugs - see Linus's rant on the subject a few months back.
Agreed. No *known* *major* security holes is fine here.
>> * works reliably, under load/stress.
> And you win the trifecta - I don't think we've *ever* shipped a Linux kernel
> that worked reliably under the proper "beat on the scheduler/VM corner case"
> load/stress testing. Again, the best you can hope for is "doesn't fall over
> under non-pathological non-corner-case loads when sufficient resources are
> available so the kernel has a fighting chance". Doing 'make -j100' on a
> single Core2 Duo is gonna be painful, no matter what.
Well the typical tests outlined above are:
* random size file creation/deletion, lots of files
* memory allocation, and freeing up again
* stressing the CPU a bit with one process, then
forking 25-50 processes to (trivially) test scheduler
* testing network I/O by rapidly/concurrently fetching
many small files via HTTP, and a few large ones.
The end goal is simply to get a server which doesn't crash under
"normal" operating conditions. The bugs I referred to in
e1000/forcedeth and r8169 either stop it PXE booting (a requirement for
our environment!) or can *easily* be made to oops / stop working.
Alex
On Wed, 22 Oct 2008 09:58:06 +0100
Alex Howells <[email protected]> wrote:
> > And you win the trifecta - I don't think we've *ever* shipped a Linux kernel
> > that worked reliably under the proper "beat on the scheduler/VM corner case"
> > load/stress testing. Again, the best you can hope for is "doesn't fall over
Upstream kernels can be a bit iffy especially on 32bit boxes with lots
of RAM. The enterprise vendor kernels have had months of tuning on high
load tests and behave far better than upstream. If you are running 32bit
and > 2GB of RAM I wouldn't even bother with upstream kernels to be
honest - pick one of the enterprise distributions or free repackagings
thereof. Better yet go 64bit ;)
At minimum with 2.6.x under high load you also need Arjan van de Ven's
patches to fix the ioprio mess - and god knows why those haven't been
accepted upstream given they make a huge difference to performance and
load handling.
http://lkml.org/lkml/2008/10/2/297
> > under non-pathological non-corner-case loads when sufficient resources are
> > available so the kernel has a fighting chance". Doing 'make -j100' on a
> > single Core2 Duo is gonna be painful, no matter what.
Turn on strict overcommit and the box will degrade sanely and then if
need be start erroring things with out of memory before it goes kersplat.
That was a feature added a long time ago by Red Hat and then merged
upstream because serious business users of Linux need better guarantees
than the base kernel defaults.
If you have a non AMD processor without an IOMMU and are doing high
amounts of I/O make sure your I/O devices are 64bit capable - particular
watch SATA as most ATA hardware that isn't AHCI is 32bit constrained.
Alan
Alex Howells wrote:
> So with regards to supported kernels, the following springs to mind:
>
> * how long is kernel 2.6.xx supported?
> * is kernel 2.6.xx one of the "longer term" supported ones?
> * what are the requirements for a maintainer to push a
> new release, a la 2.6.xx.yy? Is it based on time elapsed,
> severity of any fixes included?
> * how do we define "support" in this context?
> does it mean security problems discovered/fixed *after*
> development focus has moved on to new stuff is backported?
> does it mean [critical] bug fixes? regression fixes?
That's all quite simple to answer with a firm "depends".
1. Remember, it's all volunteer work (by companies and individuals).
2. Watch the release announcements and changelogs to learn about the
lifetimes of -stable lines (they vary due to circumstances) and
about what goes in into these lines. There are also some bits in
Documentation/stable_kernel_rules.txt.
Among else, it depends on volunteered manpower for patch verification
and even on sheer coincidence (somebody needs to be aware that an issue
is relevant to an active -stable line) whether a fix goes into -stable
or not.
Circumstances which lead to a -stable line remaining active for longer
than usual typically boil down to the motives of an individual developer
who picks up maintenance, like Adrian happened to do with 2.6.16.y and
plans to repeat with 2.6.27.y, or like Greg kept/ keeps 2.6.25.y active
alongside 2.6.26.y because it's directly useful to other work of his, AFAIU.
If you are interested in more structured release policies, you shouldn't
hesitate to have a look at vendor kernel lines.
--
Stefan Richter
-=====-==--- =-=- =-==-
http://arcgraph.de/sr/