Re: Linux 2.6.11.1
* Bill Davidsen ([EMAIL PROTECTED]) wrote: > Jeff Garzik wrote: > >>nfsd--svcrpc-add-a-per-flavor-set_client-method.patch > > > >is this critical? > > Wasn't part of the Linus proposal that it had to fix an oops or > non-functional feature? We're working on the criteria, should have some updates posted soon. One important piece is fixing a critical bug or seriously damaged feature, and another piece is subsystem maintainer signoff/advocacy. At first pass, this particular patch certainly does not look critical. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - 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/
Re: Linux 2.6.11.1
Jeff Garzik wrote: Unless it's crashing for people, stack usage is IMO a wanted-fix not needed-fix. nfsd--svcrpc-add-a-per-flavor-set_client-method.patch is this critical? Wasn't part of the Linus proposal that it had to fix an oops or non-functional feature? -- -bill davidsen ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - 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/
Re: Linux 2.6.11.1
On Mon, 2005-03-07 at 17:18 +, Alan Cox wrote: > On Sad, 2005-03-05 at 22:06, Lee Revell wrote: > > Driver updates are a hard problem. Nothing annoys users more than > > unsupported hardware. But if you aggressively add support for new > > devices you can break things that have worked for ages. > > You can however plan for them in advance. Guess why the -ac tree has an > ide > option to grab any otherwise unknown ide controller and stuff it in bios > tuned > DMA modes ? > > Similarly you can generally apply "just PCI id" patches Yup. A much simpler example is my emu10k1 multichannel patches that are in ALSA CVS now. The function of an (obscure) mixer control changes subtly, so the control is renamed to guarantee that the user gets the default setting. Lee - 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/
Re: Linux 2.6.11.1
On Mon, 2005-03-07 at 17:18 +, Alan Cox wrote: On Sad, 2005-03-05 at 22:06, Lee Revell wrote: Driver updates are a hard problem. Nothing annoys users more than unsupported hardware. But if you aggressively add support for new devices you can break things that have worked for ages. You can however plan for them in advance. Guess why the -ac tree has an ide option to grab any otherwise unknown ide controller and stuff it in bios tuned DMA modes ? Similarly you can generally apply just PCI id patches Yup. A much simpler example is my emu10k1 multichannel patches that are in ALSA CVS now. The function of an (obscure) mixer control changes subtly, so the control is renamed to guarantee that the user gets the default setting. Lee - 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/
Re: Linux 2.6.11.1
Jeff Garzik wrote: Unless it's crashing for people, stack usage is IMO a wanted-fix not needed-fix. nfsd--svcrpc-add-a-per-flavor-set_client-method.patch is this critical? Wasn't part of the Linus proposal that it had to fix an oops or non-functional feature? -- -bill davidsen ([EMAIL PROTECTED]) The secret to procrastination is to put things off until the last possible moment - but no longer -me - 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/
Re: Linux 2.6.11.1
* Bill Davidsen ([EMAIL PROTECTED]) wrote: Jeff Garzik wrote: nfsd--svcrpc-add-a-per-flavor-set_client-method.patch is this critical? Wasn't part of the Linus proposal that it had to fix an oops or non-functional feature? We're working on the criteria, should have some updates posted soon. One important piece is fixing a critical bug or seriously damaged feature, and another piece is subsystem maintainer signoff/advocacy. At first pass, this particular patch certainly does not look critical. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - 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/
Re: Linux 2.6.11.1
On Sad, 2005-03-05 at 22:06, Lee Revell wrote: > Driver updates are a hard problem. Nothing annoys users more than > unsupported hardware. But if you aggressively add support for new > devices you can break things that have worked for ages. You can however plan for them in advance. Guess why the -ac tree has an ide option to grab any otherwise unknown ide controller and stuff it in bios tuned DMA modes ? Similarly you can generally apply "just PCI id" patches - 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/
Re: Linux 2.6.11.1
On Sad, 2005-03-05 at 22:06, Lee Revell wrote: Driver updates are a hard problem. Nothing annoys users more than unsupported hardware. But if you aggressively add support for new devices you can break things that have worked for ages. You can however plan for them in advance. Guess why the -ac tree has an ide option to grab any otherwise unknown ide controller and stuff it in bios tuned DMA modes ? Similarly you can generally apply just PCI id patches - 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/
Re: Linux 2.6.11.1
Shawn Starr wrote: Sure, I can do this. Wrt to trivial patches, will these patches that go into rusty's patch bot go into Linus's tree or into the -mm tree? The reason I ask that is because a trivial patch may fix an oops if there's an off-by-one problem and typically I'd submit that to the trivial patch bot. No offense intended, but Rusty's trivial bot is often too slow for critical patches, so trivial-but-critical would be better off going to thru the x.y tree IMO. That's why I was wondering about why this tree doesn't except trivial changes. It will if they fix real problems that people are experiencing. The trivil bot and/or kernel-janitors paths for patches are better used for slow/non-critical patches, not patches that need quick attention and merging. Thanks, Shawn. On March 6, 2005 00:06, you wrote: On Sat, Mar 05, 2005 at 01:16:10AM -0500, Shawn Starr wrote: Sounds great, I can be a QA resource for what machines I have. How do people get involved in QAing these releases? Get the last release and test it out. If you have problems, and have simple/obvious patches, send them on. -- ~Randy - 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/
Re: Linux 2.6.11.1
Sure, I can do this. Wrt to trivial patches, will these patches that go into rusty's patch bot go into Linus's tree or into the -mm tree? The reason I ask that is because a trivial patch may fix an oops if there's an off-by-one problem and typically I'd submit that to the trivial patch bot. That's why I was wondering about why this tree doesn't except trivial changes. Thanks, Shawn. On March 6, 2005 00:06, you wrote: > On Sat, Mar 05, 2005 at 01:16:10AM -0500, Shawn Starr wrote: > > Sounds great, I can be a QA resource for what machines I have. > > > > How do people get involved in QAing these releases? > > Get the last release and test it out. If you have problems, and have > simple/obvious patches, send them on. > > thanks, > > greg k-h - 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/
Re: Linux 2.6.11.1
Sure, I can do this. Wrt to trivial patches, will these patches that go into rusty's patch bot go into Linus's tree or into the -mm tree? The reason I ask that is because a trivial patch may fix an oops if there's an off-by-one problem and typically I'd submit that to the trivial patch bot. That's why I was wondering about why this tree doesn't except trivial changes. Thanks, Shawn. On March 6, 2005 00:06, you wrote: On Sat, Mar 05, 2005 at 01:16:10AM -0500, Shawn Starr wrote: Sounds great, I can be a QA resource for what machines I have. How do people get involved in QAing these releases? Get the last release and test it out. If you have problems, and have simple/obvious patches, send them on. thanks, greg k-h - 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/
Re: Linux 2.6.11.1
Shawn Starr wrote: Sure, I can do this. Wrt to trivial patches, will these patches that go into rusty's patch bot go into Linus's tree or into the -mm tree? The reason I ask that is because a trivial patch may fix an oops if there's an off-by-one problem and typically I'd submit that to the trivial patch bot. No offense intended, but Rusty's trivial bot is often too slow for critical patches, so trivial-but-critical would be better off going to thru the x.y tree IMO. That's why I was wondering about why this tree doesn't except trivial changes. It will if they fix real problems that people are experiencing. The trivil bot and/or kernel-janitors paths for patches are better used for slow/non-critical patches, not patches that need quick attention and merging. Thanks, Shawn. On March 6, 2005 00:06, you wrote: On Sat, Mar 05, 2005 at 01:16:10AM -0500, Shawn Starr wrote: Sounds great, I can be a QA resource for what machines I have. How do people get involved in QAing these releases? Get the last release and test it out. If you have problems, and have simple/obvious patches, send them on. -- ~Randy - 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/
Re: Linux 2.6.11.1
On Sat, Mar 05, 2005 at 01:16:10AM -0500, Shawn Starr wrote: > Sounds great, I can be a QA resource for what machines I have. > > How do people get involved in QAing these releases? Get the last release and test it out. If you have problems, and have simple/obvious patches, send them on. thanks, greg k-h - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 08:37:28PM -0500, Jeff Garzik wrote: > Greg KH wrote: > >On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote: > > > >>But we end up with a cset in the permanent kernel history which simply > >>should not have been there. > > > > > >Is this really a big deal? > > If you are pushing linux-release to Linus/Andrew rapidly, quick fixes > will land in linux-2.6 rapidly, and more invasive stuff will land only > in linux-2.6 when the invasive stuff is ready to go. It even takes the > pressure off pushing invasive stuff ASAP. > > Have you pushed linux-2.6.11.1 upstream yet? :) Having Linus pull from the 2.6.x.y bk tree, will not work out. We probably don't want the .1, .2, and so on tags in the tree, as well as not all fixes in there will be proper for his tree (like the 2 currently in 2.6.11.1.) The "real" fix will go into his tree through the proper ways. But I/we will be sure to pick out the stuff that should go there and send them to him. thanks, greg k-h - 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/
Re: Linux 2.6.11.1
On Sat, Mar 05, 2005 at 02:53:43AM -0500, Dave Jones wrote: > On Fri, Mar 04, 2005 at 04:28:02PM -0800, Linus Torvalds wrote: > > On Fri, 4 Mar 2005, Greg KH wrote: > > > On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote: > > > > But we end up with a cset in the permanent kernel history which simply > > > > should not have been there. > > > > > > Is this really a big deal? > > > > Once? No. If it ends up being "par for the course", it's bad. > > The amount of stuff in the sucker tree shouldn't really amount > to /that/ many patches should it ? If it does, then 2.6.x is in > worse shape than we've all been admitting. > > Would it be that much work to just send the 'meat' as gnu patches, > and leave the not-for-linus stuff alone ? No it would not be, and should be the way this works. thanks, greg k-h - 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/
Re: Linux 2.6.11.1
On Saturday 05 March 2005 17:06, Lee Revell wrote: >On Sat, 2005-03-05 at 16:49 -0500, Gene Heskett wrote: >> What he said! Perfectly good patches, which fix real problems >> would appear to be sitting in testing/broken_out till bit rot or >> ???. >> >> If you want a testers testimony, I'm running the >> bk-ieee1394.patch, and all I can say at this point is that it Just >> Works(TM). I have NDI how it got a yesterdays Mar 4) date in the >> directory listing there though, I've had it a bit longer than that >> by 2-3 days as my copy shows a Mar 1 date. I first got it via svn >> fetch at linux-ieee1394.org or some such in January. >> >> Fixes for real problems that fix real problems should somehow get >> a faster track into final. The current firewire in the kernel as >> of 2.6.11 is still badly borked. > >Driver updates are a hard problem. Nothing annoys users more than >unsupported hardware. But if you aggressively add support for new >devices you can break things that have worked for ages. > >A change that makes your hardware work may break someone else's. > There is no such thing as an obviously correct patch when you are > flipping bits in the hardware. You can never eliminate 100% of > driver regressions, all you can do is minimize the impact by > getting release candidates tested on the widest possible range of > hardware. > >Lee True up to a certain extent, Lee. I did not own any firewire stuff except for a 6 year old firewire card I didn't have anything to plug into, a TI of some sort that supposedly needed the ti-linx driver, until I bought this camera. That card quickly proved to be borked per comments made on the linux-firewire list, and got replaced with a $25 belkin card from wallyworld. One buys whats available at your friendly local wallyworld as a first pass at fixing things. That worked great when it felt like it, which wasn't often. Now, with this patch, it Just Works(TM). My point is that if it doesn't get into mainline, how are you going to know it it breaks something that formerly worked? In my case, it certainly fixed something that didn't work, and didn't break anything that I know of *yet*. I have quite a managerie of accessories hanging off of the various ports, mostly usb on this box, and I have a regular tour of them I make when I reboot to a newer kernel, so if something breaks sane, or printing, networking, x10, what have you, I usually know about it within 30 minutes of the reboot. Frankly, I was surprised that this elcheapo belkin card worked so good! Their bigger ups's, and this card seem to be the exception to the mainline and very prominent story of all their broken KVM switches. A pleasant surprise in light of my reticence to even put fingerprints on many of the belkin boxes on the shelf at Staples et all. However, that doesn't address the fact that the patch I grabbed, dated Mar 1, is apparently older than the one in testing/broken_out dated Mar 4. Both are 265824 bytes long however, so I'm going to go with the theory that someone rebuilt the directory on kernel.org. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - 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/
Re: Linux 2.6.11.1
On Sat, 2005-03-05 at 16:49 -0500, Gene Heskett wrote: > What he said! Perfectly good patches, which fix real problems would > appear to be sitting in testing/broken_out till bit rot or ???. > > If you want a testers testimony, I'm running the bk-ieee1394.patch, > and all I can say at this point is that it Just Works(TM). I have > NDI how it got a yesterdays Mar 4) date in the directory listing > there though, I've had it a bit longer than that by 2-3 days as my > copy shows a Mar 1 date. I first got it via svn fetch at > linux-ieee1394.org or some such in January. > > Fixes for real problems that fix real problems should somehow get a > faster track into final. The current firewire in the kernel as of > 2.6.11 is still badly borked. Driver updates are a hard problem. Nothing annoys users more than unsupported hardware. But if you aggressively add support for new devices you can break things that have worked for ages. A change that makes your hardware work may break someone else's. There is no such thing as an obviously correct patch when you are flipping bits in the hardware. You can never eliminate 100% of driver regressions, all you can do is minimize the impact by getting release candidates tested on the widest possible range of hardware. Lee - 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/
Re: Linux 2.6.11.1
On Saturday 05 March 2005 16:17, Linus Torvalds wrote: >On Sat, 5 Mar 2005, Russell King wrote: >> On Sat, Mar 05, 2005 at 09:40:59AM -0800, Linus Torvalds wrote: >> > I love BK, but what BK does well is merging and maintaining >> > trees full of good stuff. What BK sucks at is experimental stuff >> > where you don't know whether something should be eventually used >> > or not. >> >> Wait a minute - why would stuff going into 2.6.x.y be >> "experimental" stuff? Wasn't stability the whole point of this >> tree? > >The point being that _before_ a patch gets accepted, it's in that > "limbo" state, waiting for people to veto it or say "yes". > >That limbo state is not well done with BK. > > Linus What he said! Perfectly good patches, which fix real problems would appear to be sitting in testing/broken_out till bit rot or ???. If you want a testers testimony, I'm running the bk-ieee1394.patch, and all I can say at this point is that it Just Works(TM). I have NDI how it got a yesterdays Mar 4) date in the directory listing there though, I've had it a bit longer than that by 2-3 days as my copy shows a Mar 1 date. I first got it via svn fetch at linux-ieee1394.org or some such in January. Fixes for real problems that fix real problems should somehow get a faster track into final. The current firewire in the kernel as of 2.6.11 is still badly borked. If that diff in the dates means I should update and retest, please advise. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - 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/
Re: Linux 2.6.11.1
On Sat, 5 Mar 2005, Russell King wrote: > > On Sat, Mar 05, 2005 at 09:40:59AM -0800, Linus Torvalds wrote: > > I love BK, but what BK does well is merging and maintaining trees full of > > good stuff. What BK sucks at is experimental stuff where you don't know > > whether something should be eventually used or not. > > Wait a minute - why would stuff going into 2.6.x.y be "experimental" > stuff? Wasn't stability the whole point of this tree? The point being that _before_ a patch gets accepted, it's in that "limbo" state, waiting for people to veto it or say "yes". That limbo state is not well done with BK. Linus - 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/
Re: Linux 2.6.11.1
Many, many thanks...it's a great idea and seems to go well with Linus's idea of making even releases "hyper-stable". This is exactly what I was looking for in (http://article.gmane.org/gmane.linux.kernel/268836) Sorry some of you feel like "suckers"...but you're _not_. You're heroes -- doing the hard sh*t that most programmers don't want to be bothered with. I salute you! Linda W. Greg KH wrote: 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 @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 - 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/ - 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/
Re: Linux 2.6.11.1
Linus Torvalds wrote: On Sat, 5 Mar 2005, Jeff Garzik wrote: Yup, BK could definitely handle that... However, it's also true that the thing BK is _worst_ at is cherry-picking things, and having a collection of stuff where somebody may end up vetoing one patch and saying "remove that one". So it's entirely possible that the proper tool to use for the first level is not BK at all, but the evolved patch-scripts that Andrew uses, in other words: http://savannah.nongnu.org/projects/quilt may well be a much better thing to use. I love BK, but what BK does well is merging and maintaining trees full of good stuff. What BK sucks at is experimental stuff where you don't know whether something should be eventually used or not. I almost volunteered (read: suckered) and would use patch-scripts or quilt to do the job. It (the tool) seems to be a natural fit for it (the job). However, I'm happy with Greg and Chris doing it. :) suckers. -- ~Randy - 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/
Re: Linux 2.6.11.1
Linus Torvalds wrote: On Sat, 5 Mar 2005, Jeff Garzik wrote: Yup, BK could definitely handle that... However, it's also true that the thing BK is _worst_ at is cherry-picking things, and having a collection of stuff where somebody may end up vetoing one patch and saying "remove that one". In general, I agree. Andrew and I mentioned this to BitMover recently [though its certainly not a new comment], when they asked us why I had to occasionally blow away the netdev-2.6 tree, and reconstitute it from scratch. I love BK, but what BK does well is merging and maintaining trees full of good stuff. What BK sucks at is experimental stuff where you don't know whether something should be eventually used or not. I use BitKeeper to maintain such a tree, "libata-dev". Most stuff in there will go upstream. Some stuff may never go upstream. Some stuff needs to simmer for a while before going upstream. So "change streams" get divided up locally: [EMAIL PROTECTED] libata-dev]$ ls -FC adma/ atapi-enable/janitor/remove-one-fix/ adma-mwi/ bridge-detect/ passthru/ sata-sil-irq/ ahci-msi/ chs-support/ pdc2027x/ tf-cleanup/ ahci-tf-read/ ioctl-get-identity/ pdc20619/ via-6421/ iomap/ promise-sata-pata/ and then I cherrypick from that. netdev-2.6 queue is maintained the same way. It's simply a merge tree composed of 40+ individual trees, all merged together. Jeff - 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/
Re: Linux 2.6.11.1
On Sat, Mar 05, 2005 at 09:40:59AM -0800, Linus Torvalds wrote: > I love BK, but what BK does well is merging and maintaining trees full of > good stuff. What BK sucks at is experimental stuff where you don't know > whether something should be eventually used or not. Wait a minute - why would stuff going into 2.6.x.y be "experimental" stuff? Wasn't stability the whole point of this tree? -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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/
Re: Linux 2.6.11.1
On Sat, 5 Mar 2005, Jeff Garzik wrote: > > Yup, BK could definitely handle that... However, it's also true that the thing BK is _worst_ at is cherry-picking things, and having a collection of stuff where somebody may end up vetoing one patch and saying "remove that one". So it's entirely possible that the proper tool to use for the first level is not BK at all, but the evolved patch-scripts that Andrew uses, in other words: http://savannah.nongnu.org/projects/quilt may well be a much better thing to use. I love BK, but what BK does well is merging and maintaining trees full of good stuff. What BK sucks at is experimental stuff where you don't know whether something should be eventually used or not. Linus - 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/
Re: Linux 2.6.11.1
Russell King wrote: On Fri, Mar 04, 2005 at 02:05:18PM -0800, Greg KH wrote: On Fri, Mar 04, 2005 at 01:59:33PM -0800, Andrew Morton wrote: That tree has the not-for-linus raid6 fix and the not-for-linus i8042 fix. Then when the authors of those patches go to submit the fix to Linus, they can revert them, or bk can handle the merge properly :) How about having two BK trees - one containing "fixes for Linus" and the other "fixes not for Linus but we really need" ? The "sucker tree" then becomes the two merged together. This way, Linus would never see the "fixes not for Linus" at all. Yup, BK could definitely handle that... Jeff - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 02:05:18PM -0800, Greg KH wrote: > On Fri, Mar 04, 2005 at 01:59:33PM -0800, Andrew Morton wrote: > > That tree has the not-for-linus raid6 fix and the not-for-linus i8042 fix. > > Then when the authors of those patches go to submit the fix to Linus, > they can revert them, or bk can handle the merge properly :) How about having two BK trees - one containing "fixes for Linus" and the other "fixes not for Linus but we really need" ? The "sucker tree" then becomes the two merged together. This way, Linus would never see the "fixes not for Linus" at all. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 02:05:18PM -0800, Greg KH wrote: On Fri, Mar 04, 2005 at 01:59:33PM -0800, Andrew Morton wrote: That tree has the not-for-linus raid6 fix and the not-for-linus i8042 fix. Then when the authors of those patches go to submit the fix to Linus, they can revert them, or bk can handle the merge properly :) How about having two BK trees - one containing fixes for Linus and the other fixes not for Linus but we really need ? The sucker tree then becomes the two merged together. This way, Linus would never see the fixes not for Linus at all. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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/
Re: Linux 2.6.11.1
Russell King wrote: On Fri, Mar 04, 2005 at 02:05:18PM -0800, Greg KH wrote: On Fri, Mar 04, 2005 at 01:59:33PM -0800, Andrew Morton wrote: That tree has the not-for-linus raid6 fix and the not-for-linus i8042 fix. Then when the authors of those patches go to submit the fix to Linus, they can revert them, or bk can handle the merge properly :) How about having two BK trees - one containing fixes for Linus and the other fixes not for Linus but we really need ? The sucker tree then becomes the two merged together. This way, Linus would never see the fixes not for Linus at all. Yup, BK could definitely handle that... Jeff - 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/
Re: Linux 2.6.11.1
On Sat, 5 Mar 2005, Jeff Garzik wrote: Yup, BK could definitely handle that... However, it's also true that the thing BK is _worst_ at is cherry-picking things, and having a collection of stuff where somebody may end up vetoing one patch and saying remove that one. So it's entirely possible that the proper tool to use for the first level is not BK at all, but the evolved patch-scripts that Andrew uses, in other words: http://savannah.nongnu.org/projects/quilt may well be a much better thing to use. I love BK, but what BK does well is merging and maintaining trees full of good stuff. What BK sucks at is experimental stuff where you don't know whether something should be eventually used or not. Linus - 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/
Re: Linux 2.6.11.1
On Sat, Mar 05, 2005 at 09:40:59AM -0800, Linus Torvalds wrote: I love BK, but what BK does well is merging and maintaining trees full of good stuff. What BK sucks at is experimental stuff where you don't know whether something should be eventually used or not. Wait a minute - why would stuff going into 2.6.x.y be experimental stuff? Wasn't stability the whole point of this tree? -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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/
Re: Linux 2.6.11.1
Linus Torvalds wrote: On Sat, 5 Mar 2005, Jeff Garzik wrote: Yup, BK could definitely handle that... However, it's also true that the thing BK is _worst_ at is cherry-picking things, and having a collection of stuff where somebody may end up vetoing one patch and saying remove that one. In general, I agree. Andrew and I mentioned this to BitMover recently [though its certainly not a new comment], when they asked us why I had to occasionally blow away the netdev-2.6 tree, and reconstitute it from scratch. I love BK, but what BK does well is merging and maintaining trees full of good stuff. What BK sucks at is experimental stuff where you don't know whether something should be eventually used or not. I use BitKeeper to maintain such a tree, libata-dev. Most stuff in there will go upstream. Some stuff may never go upstream. Some stuff needs to simmer for a while before going upstream. So change streams get divided up locally: [EMAIL PROTECTED] libata-dev]$ ls -FC adma/ atapi-enable/janitor/remove-one-fix/ adma-mwi/ bridge-detect/ passthru/ sata-sil-irq/ ahci-msi/ chs-support/ pdc2027x/ tf-cleanup/ ahci-tf-read/ ioctl-get-identity/ pdc20619/ via-6421/ iomap/ promise-sata-pata/ and then I cherrypick from that. netdev-2.6 queue is maintained the same way. It's simply a merge tree composed of 40+ individual trees, all merged together. Jeff - 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/
Re: Linux 2.6.11.1
Linus Torvalds wrote: On Sat, 5 Mar 2005, Jeff Garzik wrote: Yup, BK could definitely handle that... However, it's also true that the thing BK is _worst_ at is cherry-picking things, and having a collection of stuff where somebody may end up vetoing one patch and saying remove that one. So it's entirely possible that the proper tool to use for the first level is not BK at all, but the evolved patch-scripts that Andrew uses, in other words: http://savannah.nongnu.org/projects/quilt may well be a much better thing to use. I love BK, but what BK does well is merging and maintaining trees full of good stuff. What BK sucks at is experimental stuff where you don't know whether something should be eventually used or not. I almost volunteered (read: suckered) and would use patch-scripts or quilt to do the job. It (the tool) seems to be a natural fit for it (the job). However, I'm happy with Greg and Chris doing it. :) suckers. -- ~Randy - 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/
Re: Linux 2.6.11.1
Many, many thanks...it's a great idea and seems to go well with Linus's idea of making even releases hyper-stable. This is exactly what I was looking for in (http://article.gmane.org/gmane.linux.kernel/268836) Sorry some of you feel like suckers...but you're _not_. You're heroes -- doing the hard sh*t that most programmers don't want to be bothered with. I salute you! Linda W. Greg KH wrote: 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 - 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/ - 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/
Re: Linux 2.6.11.1
On Sat, 5 Mar 2005, Russell King wrote: On Sat, Mar 05, 2005 at 09:40:59AM -0800, Linus Torvalds wrote: I love BK, but what BK does well is merging and maintaining trees full of good stuff. What BK sucks at is experimental stuff where you don't know whether something should be eventually used or not. Wait a minute - why would stuff going into 2.6.x.y be experimental stuff? Wasn't stability the whole point of this tree? The point being that _before_ a patch gets accepted, it's in that limbo state, waiting for people to veto it or say yes. That limbo state is not well done with BK. Linus - 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/
Re: Linux 2.6.11.1
On Saturday 05 March 2005 16:17, Linus Torvalds wrote: On Sat, 5 Mar 2005, Russell King wrote: On Sat, Mar 05, 2005 at 09:40:59AM -0800, Linus Torvalds wrote: I love BK, but what BK does well is merging and maintaining trees full of good stuff. What BK sucks at is experimental stuff where you don't know whether something should be eventually used or not. Wait a minute - why would stuff going into 2.6.x.y be experimental stuff? Wasn't stability the whole point of this tree? The point being that _before_ a patch gets accepted, it's in that limbo state, waiting for people to veto it or say yes. That limbo state is not well done with BK. Linus What he said! Perfectly good patches, which fix real problems would appear to be sitting in testing/broken_out till bit rot or ???. If you want a testers testimony, I'm running the bk-ieee1394.patch, and all I can say at this point is that it Just Works(TM). I have NDI how it got a yesterdays Mar 4) date in the directory listing there though, I've had it a bit longer than that by 2-3 days as my copy shows a Mar 1 date. I first got it via svn fetch at linux-ieee1394.org or some such in January. Fixes for real problems that fix real problems should somehow get a faster track into final. The current firewire in the kernel as of 2.6.11 is still badly borked. If that diff in the dates means I should update and retest, please advise. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - 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/
Re: Linux 2.6.11.1
On Sat, 2005-03-05 at 16:49 -0500, Gene Heskett wrote: What he said! Perfectly good patches, which fix real problems would appear to be sitting in testing/broken_out till bit rot or ???. If you want a testers testimony, I'm running the bk-ieee1394.patch, and all I can say at this point is that it Just Works(TM). I have NDI how it got a yesterdays Mar 4) date in the directory listing there though, I've had it a bit longer than that by 2-3 days as my copy shows a Mar 1 date. I first got it via svn fetch at linux-ieee1394.org or some such in January. Fixes for real problems that fix real problems should somehow get a faster track into final. The current firewire in the kernel as of 2.6.11 is still badly borked. Driver updates are a hard problem. Nothing annoys users more than unsupported hardware. But if you aggressively add support for new devices you can break things that have worked for ages. A change that makes your hardware work may break someone else's. There is no such thing as an obviously correct patch when you are flipping bits in the hardware. You can never eliminate 100% of driver regressions, all you can do is minimize the impact by getting release candidates tested on the widest possible range of hardware. Lee - 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/
Re: Linux 2.6.11.1
On Saturday 05 March 2005 17:06, Lee Revell wrote: On Sat, 2005-03-05 at 16:49 -0500, Gene Heskett wrote: What he said! Perfectly good patches, which fix real problems would appear to be sitting in testing/broken_out till bit rot or ???. If you want a testers testimony, I'm running the bk-ieee1394.patch, and all I can say at this point is that it Just Works(TM). I have NDI how it got a yesterdays Mar 4) date in the directory listing there though, I've had it a bit longer than that by 2-3 days as my copy shows a Mar 1 date. I first got it via svn fetch at linux-ieee1394.org or some such in January. Fixes for real problems that fix real problems should somehow get a faster track into final. The current firewire in the kernel as of 2.6.11 is still badly borked. Driver updates are a hard problem. Nothing annoys users more than unsupported hardware. But if you aggressively add support for new devices you can break things that have worked for ages. A change that makes your hardware work may break someone else's. There is no such thing as an obviously correct patch when you are flipping bits in the hardware. You can never eliminate 100% of driver regressions, all you can do is minimize the impact by getting release candidates tested on the widest possible range of hardware. Lee True up to a certain extent, Lee. I did not own any firewire stuff except for a 6 year old firewire card I didn't have anything to plug into, a TI of some sort that supposedly needed the ti-linx driver, until I bought this camera. That card quickly proved to be borked per comments made on the linux-firewire list, and got replaced with a $25 belkin card from wallyworld. One buys whats available at your friendly local wallyworld as a first pass at fixing things. That worked great when it felt like it, which wasn't often. Now, with this patch, it Just Works(TM). My point is that if it doesn't get into mainline, how are you going to know it it breaks something that formerly worked? In my case, it certainly fixed something that didn't work, and didn't break anything that I know of *yet*. I have quite a managerie of accessories hanging off of the various ports, mostly usb on this box, and I have a regular tour of them I make when I reboot to a newer kernel, so if something breaks sane, or printing, networking, x10, what have you, I usually know about it within 30 minutes of the reboot. Frankly, I was surprised that this elcheapo belkin card worked so good! Their bigger ups's, and this card seem to be the exception to the mainline and very prominent story of all their broken KVM switches. A pleasant surprise in light of my reticence to even put fingerprints on many of the belkin boxes on the shelf at Staples et all. However, that doesn't address the fact that the patch I grabbed, dated Mar 1, is apparently older than the one in testing/broken_out dated Mar 4. Both are 265824 bytes long however, so I'm going to go with the theory that someone rebuilt the directory on kernel.org. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - 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/
Re: Linux 2.6.11.1
On Sat, Mar 05, 2005 at 02:53:43AM -0500, Dave Jones wrote: On Fri, Mar 04, 2005 at 04:28:02PM -0800, Linus Torvalds wrote: On Fri, 4 Mar 2005, Greg KH wrote: On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote: But we end up with a cset in the permanent kernel history which simply should not have been there. Is this really a big deal? Once? No. If it ends up being par for the course, it's bad. The amount of stuff in the sucker tree shouldn't really amount to /that/ many patches should it ? If it does, then 2.6.x is in worse shape than we've all been admitting. Would it be that much work to just send the 'meat' as gnu patches, and leave the not-for-linus stuff alone ? No it would not be, and should be the way this works. thanks, greg k-h - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 08:37:28PM -0500, Jeff Garzik wrote: Greg KH wrote: On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote: But we end up with a cset in the permanent kernel history which simply should not have been there. Is this really a big deal? If you are pushing linux-release to Linus/Andrew rapidly, quick fixes will land in linux-2.6 rapidly, and more invasive stuff will land only in linux-2.6 when the invasive stuff is ready to go. It even takes the pressure off pushing invasive stuff ASAP. Have you pushed linux-2.6.11.1 upstream yet? :) Having Linus pull from the 2.6.x.y bk tree, will not work out. We probably don't want the .1, .2, and so on tags in the tree, as well as not all fixes in there will be proper for his tree (like the 2 currently in 2.6.11.1.) The real fix will go into his tree through the proper ways. But I/we will be sure to pick out the stuff that should go there and send them to him. thanks, greg k-h - 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/
Re: Linux 2.6.11.1
On Sat, Mar 05, 2005 at 01:16:10AM -0500, Shawn Starr wrote: Sounds great, I can be a QA resource for what machines I have. How do people get involved in QAing these releases? Get the last release and test it out. If you have problems, and have simple/obvious patches, send them on. thanks, greg k-h - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 04:28:02PM -0800, Linus Torvalds wrote: > > > On Fri, 4 Mar 2005, Greg KH wrote: > > > On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote: > > > But we end up with a cset in the permanent kernel history which simply > > > should not have been there. > > > > Is this really a big deal? > > Once? No. If it ends up being "par for the course", it's bad. The amount of stuff in the sucker tree shouldn't really amount to /that/ many patches should it ? If it does, then 2.6.x is in worse shape than we've all been admitting. Would it be that much work to just send the 'meat' as gnu patches, and leave the not-for-linus stuff alone ? Dave - 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/
Re: Linux 2.6.11.1
On Fri, 4 Mar 2005, Jeff Garzik wrote: > On Fri, Mar 04, 2005 at 01:51:13PM -0800, Andrew Morton wrote: > > Jeff Garzik <[EMAIL PROTECTED]> wrote: ... > > > is this critical? > > > > Doubt it, unless the succeeding patches have a dependency on it. But the > > other patches have not been tested without this one being present. > > > > These patches have been in mm for four weeks, so it's probably OK from a > > stability POV to take them straight into linux-release. If they were > > fresher then the way to handle them would be to merge them into Linus's > > tree and backport in a couple of weeks time. > > Cool, fair enough. linux-release sounds fine. ok, 4 bits not just 2... Be frugal with the patches and don't take just *anything* that looks like a good fix. What you want is a more stable version, meaning less changes as time goes forward. I know it's the first couple days, but it looks like it could easily go the other way... Anyway, I hope this helps. James > > Jeff > > > > - > 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/ > > -- James Bourne | Email:[EMAIL PROTECTED] UNIX Systems Administration | WWW: http://www.hardrock.org Custom UNIX Programming | Linux: The choice of a GNU generation -- "All you need's an occasional kick in the philosophy." Frank Herbert - 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/
Re: Linux 2.6.11.1
Sounds great, I can be a QA resource for what machines I have. How do people get involved in QAing these releases? What other help? Shawn. > List: linux-kernel > Subject: Linux 2.6.11.1 > From: Greg KH > Date: 2005-03-04 17:53:02 > Message-ID: <20050304175302.GA29289 () kroah ! com> > [Download message RAW] > > 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 @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. - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 03:48:20PM -0500, Steven Rostedt wrote: > On Fri, 2005-03-04 at 09:53 -0800, Greg KH wrote: > > > --- > > > > 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 know this is new, but is this going to be posted on www.kernel.org? See the comments above the part you snipped off, that stated the infrastructure is still being worked on :) So yes, it will get there, hopefully, eventually... thanks, greg k-h - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 01:15:37PM -0800, Andrew Morton wrote: > Greg KH <[EMAIL PROTECTED]> 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, either he pulls them from our new 2.6.x.y tree, or they go to him through you. Either way, I'd recommend sending them to him for now, until we get this whole "procedure" worked out. > > 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. There is, I'll post an initial version of it in a bit. thanks, greg k-h - 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/
Re: Linux 2.6.11.1
Andrew Morton wrote: Greg KH <[EMAIL PROTECTED]> 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 Unless it's crashing for people, stack usage is IMO a wanted-fix not needed-fix. nfsd--svcrpc-add-a-per-flavor-set_client-method.patch is this critical? Jeff - 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/
Re: Linux 2.6.11.1
Greg KH <[EMAIL PROTECTED]> wrote: > > On Fri, Mar 04, 2005 at 01:15:37PM -0800, Andrew Morton wrote: > > Greg KH <[EMAIL PROTECTED]> 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, either he pulls them from our new 2.6.x.y tree, or they go to him > through you. Either way, I'd recommend sending them to him for now, We can do that. As long as the patches remain unaltered I assume that BK will recognise that the patch is already there, in a different cset? > until we get this whole "procedure" worked out. Yup. That's why I'm running this little experiment. Applying stimuli and seeing how we respond. Yum, cheese. - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 01:54:02PM -0800, Andrew Morton wrote: > Greg KH <[EMAIL PROTECTED]> wrote: > > > > On Fri, Mar 04, 2005 at 01:15:37PM -0800, Andrew Morton wrote: > > > Greg KH <[EMAIL PROTECTED]> 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, either he pulls them from our new 2.6.x.y tree, or they go to him > > through you. Either way, I'd recommend sending them to him for now, > > We can do that. As long as the patches remain unaltered I assume that BK > will recognise that the patch is already there, in a different cset? Yes, it can handle such a merge just fine. > > until we get this whole "procedure" worked out. > > Yup. That's why I'm running this little experiment. Applying stimuli and > seeing how we respond. Yum, cheese. /me scampers off into the corner... - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 02:34:22PM -0600, Ian Pilcher wrote: > From a purely process point of view, my concern would be making sure > that everything that goes into 2.6.X.Y (e.g. 2.6.11.1) makes it into > 2.6.X+1 (e.g. 2.6.12). It will be so. - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 01:51:13PM -0800, Andrew Morton wrote: > Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > > > 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 > > > > Unless it's crashing for people, stack usage is IMO a wanted-fix not > > needed-fix. > > Sure. The patch is bog-obvious though. > > > > > > nfsd--svcrpc-add-a-per-flavor-set_client-method.patch > > > > is this critical? > > Doubt it, unless the succeeding patches have a dependency on it. But the > other patches have not been tested without this one being present. > > > These patches have been in mm for four weeks, so it's probably OK from a > stability POV to take them straight into linux-release. If they were > fresher then the way to handle them would be to merge them into Linus's > tree and backport in a couple of weeks time. Cool, fair enough. linux-release sounds fine. Jeff - 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/
Re: Linux 2.6.11.1
Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > 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 > > Unless it's crashing for people, stack usage is IMO a wanted-fix not > needed-fix. Sure. The patch is bog-obvious though. > > > nfsd--svcrpc-add-a-per-flavor-set_client-method.patch > > is this critical? Doubt it, unless the succeeding patches have a dependency on it. But the other patches have not been tested without this one being present. These patches have been in mm for four weeks, so it's probably OK from a stability POV to take them straight into linux-release. If they were fresher then the way to handle them would be to merge them into Linus's tree and backport in a couple of weeks time. - 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/
Re: Linux 2.6.11.1
Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > > 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. > That tree has the not-for-linus raid6 fix and the not-for-linus i8042 fix. - 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/
Re: Linux 2.6.11.1
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 - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 12:44:31PM -0800, Andrew Morton wrote: > 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) Sounds like a performance thing than "oh my god the world is falling apart" type thing. Given it recovers after a few seconds, is it worth it ? Dave - 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/
Re: Linux 2.6.11.1
Greg KH wrote: On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote: But we end up with a cset in the permanent kernel history which simply should not have been there. Is this really a big deal? If you are pushing linux-release to Linus/Andrew rapidly, quick fixes will land in linux-2.6 rapidly, and more invasive stuff will land only in linux-2.6 when the invasive stuff is ready to go. It even takes the pressure off pushing invasive stuff ASAP. Have you pushed linux-2.6.11.1 upstream yet? :) Jeff - 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/
Re: Linux 2.6.11.1
Andrew Morton wrote: Greg KH <[EMAIL PROTECTED]> 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? linux-release team should send a "please pull" request to Linus. Jeff - 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/
Re: Linux 2.6.11.1
On Fri, 4 Mar 2005, Greg KH wrote: > On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote: > > But we end up with a cset in the permanent kernel history which simply > > should not have been there. > > Is this really a big deal? Once? No. If it ends up being "par for the course", it's bad. Linus - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote: > But we end up with a cset in the permanent kernel history which simply > should not have been there. Is this really a big deal? thanks, greg k-h - 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/
Re: Linux 2.6.11.1
Greg KH <[EMAIL PROTECTED]> wrote: > > On Fri, Mar 04, 2005 at 01:59:33PM -0800, Andrew Morton wrote: > > Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > 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. > > > > > > > That tree has the not-for-linus raid6 fix and the not-for-linus i8042 fix. > > Then when the authors of those patches go to submit the fix to Linus, > they can revert them, or bk can handle the merge properly :) > Well yeah. That's what I mentioned yesterday - I revert the notfix while merging up the realfix. OK for really small stuff, but it could get messy. We'll see. But we end up with a cset in the permanent kernel history which simply should not have been there. - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 12:44:31PM -0800, Andrew Morton wrote: > Here's the list of things which we might choose to put into 2.6.11.2. ... > nfsd--exportfs-reduce-stack-usage.patch ... Different people want different things with our 2.6.x.y. I would hope that criteria include (i) patch is obvious, and (ii) patch fixes an embarrassing flaw. I see no reason to include random small improvements. (Always some of these small improvements will be a mistake, so, in .y, when something is not really broken, don't fix it. Maybe people were actually seeing stack overflows here?) Andries >> From: NeilBrown <[EMAIL PROTECTED]> >> >> find_exported_dentry() declares >>char nbuf[NAME_MAX+1]; >> in 2 separate places, and gcc allocates space on the stack for both >> of them. Having just one of them will suffice, if we can put put >> with its scope. >> >> Reduces function stack usage on x86-32 from 0x230 to 0x130. - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 01:59:33PM -0800, Andrew Morton wrote: > Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > > > > > > 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. > > > > That tree has the not-for-linus raid6 fix and the not-for-linus i8042 fix. Then when the authors of those patches go to submit the fix to Linus, they can revert them, or bk can handle the merge properly :) thanks, greg k-h - 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/
Re: Linux 2.6.11.1
Greg KH <[EMAIL PROTECTED]> 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 ;) - 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/
Re: Linux 2.6.11.1
fr den 04.03.2005 Klokka 12:44 (-0800) skreiv Andrew Morton: > 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) Well, yes, but more importantly, they should also fix a problem with reboot recovery on the client side. Currently, if rpc.statd sends an RPC call down to lockd in order to notify it of a reboot of the server, the sunrpc server code will try to authenticate that RPC call by doing an upcall to rpc.mountd Doh! Cheers, Trond -- Trond Myklebust <[EMAIL PROTECTED]> - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 12:44:31PM -0800, Andrew Morton wrote: > Greg KH <[EMAIL PROTECTED]> 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 - 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/
Re: Linux 2.6.11.1
On Fri, 2005-03-04 at 12:53 -0800, Greg KH wrote: > See the comments above the part you snipped off, that stated the > infrastructure is still being worked on :) > Damn, I somehow missed that paragraph. Well, I've read the whole darn thread and still am getting work done. I guess I've overextended a little. Hopefully this all works out, and thanks for taking this on. -- Steve - 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/
Re: Linux 2.6.11.1
Greg KH <[EMAIL PROTECTED]> 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) - 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/
Re: Linux 2.6.11.1
From a purely process point of view, my concern would be making sure that everything that goes into 2.6.X.Y (e.g. 2.6.11.1) makes it into 2.6.X+1 (e.g. 2.6.12). -- Ian Pilcher[EMAIL PROTECTED] - 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/
Re: Linux 2.6.11.1
On Fri, 2005-03-04 at 09:53 -0800, Greg KH wrote: > --- > > 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 know this is new, but is this going to be posted on www.kernel.org? Like you don't have enough on your plate already! -- Steve - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 08:28:58PM +0100, Paolo wrote: > Out of curiosity, are you going to include the -as branch ? The whole thing? No, see previous comments about the contents of the -as and -ac "branches" in the big lkml thread. But if people will forward on bits and pieces of the -as and -ac tree, to us, and the patches meet the critera we have set up, then I do not see any problem with accepting them. thanks, gre k-h - 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/
Re: Linux 2.6.11.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg KH wrote: | On Fri, Mar 04, 2005 at 08:28:58PM +0100, Paolo wrote: | |>Out of curiosity, are you going to include the -as branch ? | | | The whole thing? No, see previous comments about the contents of the | -as and -ac "branches" in the big lkml thread. Right, the whole -as tree is really too much ;) | But if people will forward on bits and pieces of the -as and -ac tree, | to us, and the patches meet the critera we have set up, then I do not | see any problem with accepting them. Ok, hopefully that will become reality. Paolo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCKL6VxcZDms2c3jQRAkZ4AKDKk8m3OiBJs5j6WnSIm9jGdnuZogCeIzDE QeoyAI0JaQzPjZm4UR2q1Oo= =7dic -END PGP SIGNATURE- - 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/
Re: Linux 2.6.11.1
Paolo wrote: Out of curiosity, are you going to include the -as branch ? The -as stuff should be built on top of 2.6.11.X. 2.6.11.X should not be "every fix under the sun, until 2.6.12 is released." Jeff - 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/
Re: Linux 2.6.11.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 | 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 @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. First of all, congratulation. I really think this will be a great improvement to the development process. I couldn't agree more with this decision, it's really what I suggested a few months ago: http://marc.theaimsgroup.com/?l=linux-kernel=109882220123966=2 Out of curiosity, are you going to include the -as branch ? Paolo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCKLb6xcZDms2c3jQRAkmBAJ9fNXkoo+ATm2wezsRyQzrRxh6siACdFzVo 0cllOTLr40ALnK2S3VJENa0= =jWOp -END PGP SIGNATURE- - 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/
Linux 2.6.11.1
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 @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 - 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/
Re: Linux 2.6.11.1
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
#include
@@ -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.uc2005-03-04 09:27:15 -08:00
+++ b/drivers/md/raid6altivec.uc2005-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
-
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/
Re: Linux 2.6.11.1
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.uc2005-03-04 09:27:15 -08:00
+++ b/drivers/md/raid6altivec.uc2005-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
-
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/
Linux 2.6.11.1
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 - 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/
Re: Linux 2.6.11.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 | 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. First of all, congratulation. I really think this will be a great improvement to the development process. I couldn't agree more with this decision, it's really what I suggested a few months ago: http://marc.theaimsgroup.com/?l=linux-kernelm=109882220123966w=2 Out of curiosity, are you going to include the -as branch ? Paolo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCKLb6xcZDms2c3jQRAkmBAJ9fNXkoo+ATm2wezsRyQzrRxh6siACdFzVo 0cllOTLr40ALnK2S3VJENa0= =jWOp -END PGP SIGNATURE- - 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/
Re: Linux 2.6.11.1
Paolo wrote: Out of curiosity, are you going to include the -as branch ? The -as stuff should be built on top of 2.6.11.X. 2.6.11.X should not be every fix under the sun, until 2.6.12 is released. Jeff - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 08:28:58PM +0100, Paolo wrote: Out of curiosity, are you going to include the -as branch ? The whole thing? No, see previous comments about the contents of the -as and -ac branches in the big lkml thread. But if people will forward on bits and pieces of the -as and -ac tree, to us, and the patches meet the critera we have set up, then I do not see any problem with accepting them. thanks, gre k-h - 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/
Re: Linux 2.6.11.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg KH wrote: | On Fri, Mar 04, 2005 at 08:28:58PM +0100, Paolo wrote: | |Out of curiosity, are you going to include the -as branch ? | | | The whole thing? No, see previous comments about the contents of the | -as and -ac branches in the big lkml thread. Right, the whole -as tree is really too much ;) | But if people will forward on bits and pieces of the -as and -ac tree, | to us, and the patches meet the critera we have set up, then I do not | see any problem with accepting them. Ok, hopefully that will become reality. Paolo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCKL6VxcZDms2c3jQRAkZ4AKDKk8m3OiBJs5j6WnSIm9jGdnuZogCeIzDE QeoyAI0JaQzPjZm4UR2q1Oo= =7dic -END PGP SIGNATURE- - 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/
Re: Linux 2.6.11.1
On Fri, 2005-03-04 at 09:53 -0800, Greg KH wrote: --- 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 know this is new, but is this going to be posted on www.kernel.org? Like you don't have enough on your plate already! -- Steve - 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/
Re: Linux 2.6.11.1
From a purely process point of view, my concern would be making sure that everything that goes into 2.6.X.Y (e.g. 2.6.11.1) makes it into 2.6.X+1 (e.g. 2.6.12). -- Ian Pilcher[EMAIL PROTECTED] - 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/
Re: Linux 2.6.11.1
Greg KH [EMAIL PROTECTED] 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) - 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/
Re: Linux 2.6.11.1
On Fri, 2005-03-04 at 12:53 -0800, Greg KH wrote: See the comments above the part you snipped off, that stated the infrastructure is still being worked on :) Damn, I somehow missed that paragraph. Well, I've read the whole darn thread and still am getting work done. I guess I've overextended a little. Hopefully this all works out, and thanks for taking this on. -- Steve - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 12:44:31PM -0800, Andrew Morton wrote: Greg KH [EMAIL PROTECTED] 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 - 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/
Re: Linux 2.6.11.1
fr den 04.03.2005 Klokka 12:44 (-0800) skreiv Andrew Morton: 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) Well, yes, but more importantly, they should also fix a problem with reboot recovery on the client side. Currently, if rpc.statd sends an RPC call down to lockd in order to notify it of a reboot of the server, the sunrpc server code will try to authenticate that RPC call by doing an upcall to rpc.mountd Doh! Cheers, Trond -- Trond Myklebust [EMAIL PROTECTED] - 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/
Re: Linux 2.6.11.1
Greg KH [EMAIL PROTECTED] 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 ;) - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 01:59:33PM -0800, Andrew Morton wrote: Linus Torvalds [EMAIL PROTECTED] wrote: 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. That tree has the not-for-linus raid6 fix and the not-for-linus i8042 fix. Then when the authors of those patches go to submit the fix to Linus, they can revert them, or bk can handle the merge properly :) thanks, greg k-h - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 12:44:31PM -0800, Andrew Morton wrote: Here's the list of things which we might choose to put into 2.6.11.2. ... nfsd--exportfs-reduce-stack-usage.patch ... Different people want different things with our 2.6.x.y. I would hope that criteria include (i) patch is obvious, and (ii) patch fixes an embarrassing flaw. I see no reason to include random small improvements. (Always some of these small improvements will be a mistake, so, in .y, when something is not really broken, don't fix it. Maybe people were actually seeing stack overflows here?) Andries From: NeilBrown [EMAIL PROTECTED] find_exported_dentry() declares char nbuf[NAME_MAX+1]; in 2 separate places, and gcc allocates space on the stack for both of them. Having just one of them will suffice, if we can put put with its scope. Reduces function stack usage on x86-32 from 0x230 to 0x130. - 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/
Re: Linux 2.6.11.1
Greg KH [EMAIL PROTECTED] wrote: On Fri, Mar 04, 2005 at 01:59:33PM -0800, Andrew Morton wrote: Linus Torvalds [EMAIL PROTECTED] wrote: 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. That tree has the not-for-linus raid6 fix and the not-for-linus i8042 fix. Then when the authors of those patches go to submit the fix to Linus, they can revert them, or bk can handle the merge properly :) Well yeah. That's what I mentioned yesterday - I revert the notfix while merging up the realfix. OK for really small stuff, but it could get messy. We'll see. But we end up with a cset in the permanent kernel history which simply should not have been there. - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote: But we end up with a cset in the permanent kernel history which simply should not have been there. Is this really a big deal? thanks, greg k-h - 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/
Re: Linux 2.6.11.1
On Fri, 4 Mar 2005, Greg KH wrote: On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote: But we end up with a cset in the permanent kernel history which simply should not have been there. Is this really a big deal? Once? No. If it ends up being par for the course, it's bad. Linus - 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/
Re: Linux 2.6.11.1
Andrew Morton wrote: Greg KH [EMAIL PROTECTED] 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? linux-release team should send a please pull request to Linus. Jeff - 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/
Re: Linux 2.6.11.1
Greg KH wrote: On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote: But we end up with a cset in the permanent kernel history which simply should not have been there. Is this really a big deal? If you are pushing linux-release to Linus/Andrew rapidly, quick fixes will land in linux-2.6 rapidly, and more invasive stuff will land only in linux-2.6 when the invasive stuff is ready to go. It even takes the pressure off pushing invasive stuff ASAP. Have you pushed linux-2.6.11.1 upstream yet? :) Jeff - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 12:44:31PM -0800, Andrew Morton wrote: 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) Sounds like a performance thing than oh my god the world is falling apart type thing. Given it recovers after a few seconds, is it worth it ? Dave - 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/
Re: Linux 2.6.11.1
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 - 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/
Re: Linux 2.6.11.1
Linus Torvalds [EMAIL PROTECTED] wrote: 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. That tree has the not-for-linus raid6 fix and the not-for-linus i8042 fix. - 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/
Re: Linux 2.6.11.1
Jeff Garzik [EMAIL PROTECTED] wrote: 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 Unless it's crashing for people, stack usage is IMO a wanted-fix not needed-fix. Sure. The patch is bog-obvious though. nfsd--svcrpc-add-a-per-flavor-set_client-method.patch is this critical? Doubt it, unless the succeeding patches have a dependency on it. But the other patches have not been tested without this one being present. These patches have been in mm for four weeks, so it's probably OK from a stability POV to take them straight into linux-release. If they were fresher then the way to handle them would be to merge them into Linus's tree and backport in a couple of weeks time. - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 01:51:13PM -0800, Andrew Morton wrote: Jeff Garzik [EMAIL PROTECTED] wrote: 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 Unless it's crashing for people, stack usage is IMO a wanted-fix not needed-fix. Sure. The patch is bog-obvious though. nfsd--svcrpc-add-a-per-flavor-set_client-method.patch is this critical? Doubt it, unless the succeeding patches have a dependency on it. But the other patches have not been tested without this one being present. These patches have been in mm for four weeks, so it's probably OK from a stability POV to take them straight into linux-release. If they were fresher then the way to handle them would be to merge them into Linus's tree and backport in a couple of weeks time. Cool, fair enough. linux-release sounds fine. Jeff - 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/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 02:34:22PM -0600, Ian Pilcher wrote: From a purely process point of view, my concern would be making sure that everything that goes into 2.6.X.Y (e.g. 2.6.11.1) makes it into 2.6.X+1 (e.g. 2.6.12). It will be so. - 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/
