Greg KH announced the first maintenance release of the 2.6.11 kernel [story], 2.6.11.1. Quickly acting on the recent lengthy discussion regarding kernel release numbering [story] [story], Greg and Chris Wright have begun to maintain this branch. With each 2.6.x release, they will maintain 2.6.x.y releases available from your nearest kernel.org mirror. This first maintenance release includes three simple patches, not including the makefile change, addressing a problem with keyboards on Dell machines, and raid6 compilation on the ppc architecture. Andrew Morton [interview] noted that he has additional fixes appropriate for this tree that will likely lead to a 2.6.11.2 release in the relatively near future.
Greg went on to highlight the requirements for patches to be able to be merged into this new tree: they must be no bigger than 100 lines, they must fix only one thing, they must fix real bugs that are confirmed to be affecting people, and they must fix a build error, an oops, a hang, or a real security issue. Patches explicitly not allowed include things to fix "theoretical race conditions" without an exploit, or "trivial" fixes like spelling changes or whitespace cleanups. Greg described the effort's mantra as "release early and often".
From: Greg KH [email blocked] To: linux-kernel Subject: Linux 2.6.11.1 Date: Fri, 4 Mar 2005 09:53:02 -0800 For those of you who haven't waded through the huge "RFD: Kernel release numbering" thread on lkml to realize that we are now going to start putting out 2.6.x.y releases, here's the summary: A few of us $suckers will be trying to maintain a 2.6.x.y set of releases that happen after 2.6.x is released. It will contain only a set of bugfixes and security fixes that meet a strict set of guidelines, as defined by Linus at: http://article.gmane.org/gmane.linux.kernel/283396 Chris Wright and I are going to start working on doing this work, we will have a <SOME_ALIAS>@kernel.org to post these types of bug fixes to, and a set of people we bounce the patches off of to test for "smells good" validation. We will also have a bk-commits type mailing list for those who want to watch the patches flow in, and a bk tree from which changsets can be pulled from. Chris and I will be hashing all of the details out next Tuesday, and hopefully all the infrastructure will be in place soon. When that happens, we will post the full details on how all of this is going to work. In the meantime, feel free to CC: me and Chris on patches that everyone thinks should go into the 2.6.11.y releases. But right now, Chris is on a plane, and we don't have the email alias set up, or the proper permissions set up on kernel.org to push changes into the v2.6 directory, but we have a few bugs that are needing to be fixed in the 2.6.11 release. And since our mantra is, "release early and often", here's the first release. --------------- I've released the 2.6.11.1 patch: kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/patch-2.6.11.1.gz With a detailed changelog at: kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/ChangeLog-2.6.11.1 A bitkeeper tree for the 2.6.11.y releases can be found at: bk://linux-release.bkbits.net/linux-2.6.11 The diffstat and short summary of the fixes are below. I'll also be replying to this message with a copy of the patch itself, as it is small enough to do so. thanks, greg k-h ------- Makefile | 2 +- drivers/input/serio/i8042-x86ia64io.h | 6 +++--- drivers/md/raid6altivec.uc | 4 ++++ 3 files changed, 8 insertions(+), 4 deletions(-) Summary of changes from v2.6.11 to v2.6.11.1 ============================================ Dmitry Torokhov: o Fix keyboards for Dell machines Greg Kroah-Hartman: o Linux 2.6.11.1 Olof Johansson: o Fix for trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec Rene Rebe: o trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
From: Greg KH [email blocked] Subject: Re: Linux 2.6.11.1 Date: Fri, 4 Mar 2005 09:53:50 -0800 On Fri, Mar 04, 2005 at 09:53:02AM -0800, Greg KH wrote: > I'll also be replying to this message with a copy of the patch itself, > as it is small enough to do so. Here it is.... diff -Nru a/Makefile b/Makefile --- a/Makefile 2005-03-04 09:27:15 -08:00 +++ b/Makefile 2005-03-04 09:27:15 -08:00 @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 11 -EXTRAVERSION = +EXTRAVERSION = .1 NAME=Woozy Numbat # *DOCUMENTATION* diff -Nru a/drivers/input/serio/i8042-x86ia64io.h b/drivers/input/serio/i8042-x86ia64io.h --- a/drivers/input/serio/i8042-x86ia64io.h 2005-03-04 09:27:15 -08:00 +++ b/drivers/input/serio/i8042-x86ia64io.h 2005-03-04 09:27:15 -08:00 @@ -88,7 +88,7 @@ }; #endif -#ifdef CONFIG_ACPI +#if defined(__ia64__) && defined(CONFIG_ACPI) #include <linux/acpi.h> #include <acpi/acpi_bus.h> @@ -281,7 +281,7 @@ i8042_kbd_irq = I8042_MAP_IRQ(1); i8042_aux_irq = I8042_MAP_IRQ(12); -#ifdef CONFIG_ACPI +#if defined(__ia64__) && defined(CONFIG_ACPI) if (i8042_acpi_init()) return -1; #endif @@ -300,7 +300,7 @@ static inline void i8042_platform_exit(void) { -#ifdef CONFIG_ACPI +#if defined(__ia64__) && defined(CONFIG_ACPI) i8042_acpi_exit(); #endif } diff -Nru a/drivers/md/raid6altivec.uc b/drivers/md/raid6altivec.uc --- a/drivers/md/raid6altivec.uc 2005-03-04 09:27:15 -08:00 +++ b/drivers/md/raid6altivec.uc 2005-03-04 09:27:15 -08:00 @@ -108,7 +108,11 @@ int raid6_have_altivec(void) { /* This assumes either all CPUs have Altivec or none does */ +#ifdef CONFIG_PPC64 return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC; +#else + return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC; +#endif } #endif
From: Andrew Morton [email blocked] Subject: Re: Linux 2.6.11.1 Date: Fri, 4 Mar 2005 12:44:31 -0800 Greg KH [email blocked] wrote: > > A few of us $suckers will be trying to maintain a 2.6.x.y set of > releases that happen after 2.6.x is released. Just to test things out a bit... Here's the list of things which we might choose to put into 2.6.11.2. I was planning on sending them in for 2.6.12 when that was going to be errata-only. >From 2.6.11-mm1: cramfs-small-stat2-fix.patch setup_per_zone_lowmem_reserve-oops-fix.patch dv1394-ioctl-retval-fix.patch ppc32-compilation-fixes-for-ebony-luan-and-ocotea.patch nfsd--sgi-921857-find-broken-with-nohide-on-nfsv3.patch nfsd--exportfs-reduce-stack-usage.patch nfsd--svcrpc-add-a-per-flavor-set_client-method.patch nfsd--svcrpc-rename-pg_authenticate.patch nfsd--svcrpc-move-export-table-checks-to-a-per-program-pg_add_client-method.patch nfsd--nfs4-use-new-pg_set_client-method-to-simplify-nfs4-callback-authentication.patch nfsd--lockd-dont-try-to-match-callback-requests-against-export-table.patch audit-mips-fix.patch make-st-seekable-again.patch wrt the nfsd patches, Neil said: The problem they fix is that currently: Client A holds a lock Client B tries to get the lock and blocks Client A drops the lock **Client B doesn't get the lock immediately, but has to wait for a timeout. (several seconds)
From: Greg KH [email blocked] Subject: Re: Linux 2.6.11.1 Date: Fri, 4 Mar 2005 12:58:43 -0800 On Fri, Mar 04, 2005 at 12:44:31PM -0800, Andrew Morton wrote: > Greg KH [email blocked] wrote: > > > > A few of us $suckers will be trying to maintain a 2.6.x.y set of > > releases that happen after 2.6.x is released. > > Just to test things out a bit... > > Here's the list of things which we might choose to put into 2.6.11.2. I was > planning on sending them in for 2.6.12 when that was going to be > errata-only. Ok, care to forward them on? > From 2.6.11-mm1: > > cramfs-small-stat2-fix.patch > setup_per_zone_lowmem_reserve-oops-fix.patch > dv1394-ioctl-retval-fix.patch > ppc32-compilation-fixes-for-ebony-luan-and-ocotea.patch > nfsd--sgi-921857-find-broken-with-nohide-on-nfsv3.patch > nfsd--exportfs-reduce-stack-usage.patch > nfsd--svcrpc-add-a-per-flavor-set_client-method.patch > nfsd--svcrpc-rename-pg_authenticate.patch > nfsd--svcrpc-move-export-table-checks-to-a-per-program-pg_add_client-method.patch > nfsd--nfs4-use-new-pg_set_client-method-to-simplify-nfs4-callback-authentication.patch > nfsd--lockd-dont-try-to-match-callback-requests-against-export-table.patch > audit-mips-fix.patch > make-st-seekable-again.patch > > wrt the nfsd patches, Neil said: > > The problem they fix is that currently: > Client A holds a lock > Client B tries to get the lock and blocks > Client A drops the lock > **Client B doesn't get the lock immediately, but has to wait for a > timeout. (several seconds) Hm, odds are the nfsd one doesn't fit our list of "acceptable things", but let's see the patches... thanks, greg k-h
From: Andrew Morton [email blocked] Subject: Re: Linux 2.6.11.1 Date: Fri, 4 Mar 2005 13:15:37 -0800 Greg KH [email blocked] wrote: > > > Here's the list of things which we might choose to put into 2.6.11.2. I was > > planning on sending them in for 2.6.12 when that was going to be > > errata-only. > > Ok, care to forward them on? Sure. How do they get to Linus? > Hm, odds are the nfsd one doesn't fit our list of "acceptable things", Was there such a list? It's kinda what I'm asking about here. Yes, the NFSD fixes are relatively minor, although Neil did want them in the 2.6.12 errata kernel. Perhaps they could be backported to 2.6.11.x in a few weeks ;)
From: Linus Torvalds [email blocked] Subject: Re: Linux 2.6.11.1 Date: Fri, 4 Mar 2005 13:53:47 -0800 (PST) On Fri, 4 Mar 2005, Andrew Morton wrote: > > > > Ok, care to forward them on? > > Sure. How do they get to Linus? I'll just pull from the sucker-tree. Linus
From: Greg KH [email blocked] Subject: [RFQ] Rules for accepting patches into the linux-releases tree Date: Fri, 4 Mar 2005 14:21:46 -0800 Anything else anyone can think of? Any objections to any of these? I based them off of Linus's original list. thanks, greg k-h ------ Rules on what kind of patches are accepted, and what ones are not, into the "linux-release" tree. - It can not bigger than 100 lines, with context. - It must fix only one thing. - It must fix a real bug that bothers people (not a, "This could be a problem..." type thing.) - It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, or a real security issue. - No "theoretical race condition" issues, unless an explanation of how the race can be exploited. - It can not contain any "trivial" fixes in it (spelling changes, whitespace cleanups, etc.)
I want ketchup!
No wait, it isn't spam! I've been using ketchup for a while but it doesn't cover the newer trees and it surely doesn't deal with the x.y.z.!! kernel numbers. Give me a new version of ketchup!
Maintaining 2.6.8.2, 2.6.11.7, 2.6.12.4, 2.6.13.5, 2.6.14.2, ...
NOOOOOOOOOooooooooooooooooo!!!!!
;DDDDDD
The consensus is to stop main
The consensus is to stop maintaining 2.6.x.y when 2.6.x+1 is released.
Then you start over with 2.6.x+1.1
Otherwise $suckers would go mad. MAD I TELL YOU! ;)
Check out the previous article on the subject here at kerneltrap.
I think they should stop main
I think they should stop maintaining 2.6.x.y when 2.6.x+2 is released. This way, the 2.6.x.y release has more time to become really stable, and those folks who don't want to upgrade will get fixes for a reasonable amount of time.
Of course, the problem is eventually some security problem will be found, like a local privilege escalation in the kernel, and those people formerly happily running 2.6.x.y where x is four revs behind, will be out of luck unless someone is kind enough to backport a patch for them.
-Zorin
This may sound like a good id
This may sound like a good idea but really isn't practical. Good luck finding someone who wants to keep doing repetitive and boring maintanance on a singular version of the kernel for that long.
I think current release engin
I think current release engineering of 2.6.x.y is perfect (as it is free for us!) any way most of us using Distro kernel anyway. And any sane people will suggest to use distro kernel for production system or faint hearted people. maintaing sucker tree is also helps Linus & Andrew Morton as they know which of the fixes are trivial but important ....
The $sucker tree should leech
The $sucker tree should leech bugfixes and security patches off the 2.6.x+1 development tree.
I think right now people will be dumping bug fixes on the $sucker tree. Development would be done on 2.6.x+1 then later Linux would "pull" the bug fixes and security fixes from the $sucker tree.
Why ask here?
I've got a radical idea. Why don't you try emailing Matt Mackall (mpm@selenic.com) the creator/maintainer of Ketchup.
I wish firefox would "release early and often"
I just noticed a week back mozilla released firefox 1.0.1. Its the first patch in like 4 months.
If you want updates quicker w
If you want updates quicker why not run nightly builds?
Nightly builds are development releases
I am more interested in stability.
Then you understand the reaso
Then you understand the reasoning behind taking their time and testing their patches, right?
Geez It takes 4 months to release a few patches?
Now this is not the same as the kernel where they modify over 200k lines of code in every release. And they cycle every 1-2 months.
Agree
I agree with You!
Why patch something if its no
Why patch something if its not broken? There aren't exactly a boatload of new features waiting to be shoved into firefox.
No incentive to update; its small non-critical fixes
Just 3 or 4 bug fixes. There's no real incentive to get the next stable release.
Unless of course it affects y
Unless of course it affects you, like those people running Dells that can't use their keyboard.
Thats not included in 2.6.11.1 (n/t)
n/t
Less typing, more reading
Dmitry Torokhov:
o Fix keyboards for Dell machines
What the hell
Why won't they allow "trivial" fixes like spelling changes or whitespace cleanups." in .z releases.
no trivial fixes makes sense
That new tree is supposed to be for patches that fix real problems, not just trivial spelling errors or whitespace changes.
Every time you accept a patch into the tree there's always a risk the patch might break something, and the smaller the change is, the lower that risk. Cluttering up patches for this sort of tree with lots of changes to the code layout, spelling fixes, etc just make the patches harder to read/review and increase the risk an error is overlooked. Besides, "trivial" patches are usually defined as patches that have no actual impact on the generated code, so for a "fixes for real issues only" tree they are pretty irrelevant in any case.. such cleanups have no trouble waiting for the next 2.6.x+1 kernel, so they should just be merged into Linus' tree, not this new one.
spellin
Because some people write scripts which depend on those spelig erors, and cont ont hem bing theer. -);
Because maintianing and updat
Because maintianing and updating to a .z release is already a pain, so may as well make it worth something. Spelling changes and whitespace cleanups offer ZERO change in functionality and thus are nothing but extra noise in the diffs. They detract from the (purposefully) limited value the .z releases offer.
It's worth remembering that the .y+1 release is not based off of the .y.z release in any way. A .y.z release is a dead end fork that is maintained entirely in parallel with the development of the .y+1 release. Thus, there is no tangible benefit to adding "turd polishing" patches to a dead end tree. It just makes more work for $SUCKER and $END_USER with no benefit to either.
(Ok, there's precisely one theoretical tangible benefit I can think of: It *might* make it easier to apply the same patch to .y+1 and .y.z. But, then, the same could be said of any patch that's part of .y+1. Get over it.)
Actually Linus said he would
Actually Linus said he would be pulling from the "sucker-tree". So y+1 will be based on y.z. You are right though that spelling fixes would be a stupid thing to put in the .z releases.
The -as patchset
I wonder what will happen to the -as patchset now. IIRC it was made only to fix issues in the same way as theese new .z releases.
re: The -as patchset
Andres answers your question here.
why not dump the patchlevel instead ?
Rather than having 2.6.x.y, we could change to 3.x.y
and then we're almost back to previous numbering system.
... ok, except for the even/odd feature.
A 3.x.y tree would be teh nex
A 3.x.y tree would be teh next stable tree after a MAJOR kernel over haul, i.e. breaks nearly all backwards compatiblity, total code rewrite.
The 2.6.y.z is strictly to patch REAL bugs in the current stable release only, like the Dell keyboard issue. Basiclly a new stable will get release, and if suddenly the bug tracker lights up like a X-mass tree ( see Dell keyboard bug), a patch and release can be done on the relaese number instead of having to wait or speed up a an x+1 release. Also this will make live better on none core-kernel patch maintainers.
Why doesnt 2.6.11.1 replace t
Why doesnt 2.6.11.1 replace the 2.6.11 on the official kernel.org site & mirrors?
That makes definitly _no_ sen
That makes definitly _no_ sense. You have a certain kernel now, you add patches and you would name it the same version??? - That would mean, that you loose the consitancy of the data.
You would need to have another information, a timestamp. And with this timestamp, you can better take a new kernel name than confusing all people.
Best,
Marcus
Like 2.6.8
I think the OP was suggesting something similar to what happened with 2.6.8 -> 2.6.8.1, in that the first kernel you see listed on kernel.org is the 'fixed' one. Indeed, why not put 2.6.11.1 on the kernel.org index page?
OP here, yes that is what I m
OP here, yes that is what I meant. Whats the point of this stable tree if its hidden and you have to go to sites like this to get a link to it.
Sad but
Sad but true,
----
elPoeta
Poemas de amor
Real sad
Yeah, real sad :roll:
why not put 2.6.11.1 on the page? because
For every freeking stable release they would have to release the full source code (30megabytes).
No 2.6.11.1 patch on kernel.org?
Interestingly, kernel.org doesn't seem to have picked up the 2.6.11.1 patch yet. I imagine once it does, its scripts will automatically make 2.6.11.1 "latest," and it'll probably generate full tarballs (in .tar.gz and .tar.bz2 formats) for 2.6.11.1.
I see no reason why they shouldn't do it this way. They have tarballs for 2.6.8.1.
Yes they have
Its been there the whole time: http://kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/
[ignore this post]
[ignore this post. lag caused me to submit a double post. real post below.]
Ok, but it wasn't in the main
Ok, but it wasn't in the main /pub/linux/kernel/v2.6 directory, and that's what all the scripts look at, and it's where most people go when they want the "Latest 2.6 kernel." It appears to be there now.
They fixed it, maybe they too
They fixed it, maybe they took our advice to heart :)
Fixed!
Yup, i think they have fixed it. They are really good.
Are they Fixed?
Are they fixed?
err.... what do you think the
err.... what do you think they do for every other release on kernel.org?
re
I think there was some bug found.
Linux
May i know what bugs they have found?
I want to know too........
I want to know too........
where did all the comments go
where did all the comments go?