Messages in this thread | | | Date | Sat, 23 Sep 2006 06:56:10 +0200 | From | Willy Tarreau <> | Subject | Re: Linux 2.6.16.30-pre1 |
| |
Hi Greg, Hi Adrian,
On Fri, Sep 22, 2006 at 04:09:28PM -0700, Greg KH wrote:
> If you want to accept new drivers and backports like this, I think you > will find it very hard to determine what to say yes or no to in the > future. It's the main problem that everyone who has tried to maintain a > stable tree has run into, that is why we set up the -stable rules to be > what they are for that very reason.
When I started the 2.4-hotfix tree nearly two years ago, I wanted to avoid merging drivers changes as much as possible. And particularly, I avoided to add support for new hardware. The reason is very simple. I want to be able to guarantee that if 2.4.X works, then any 2.4.X.Y does too so that they can blindly upgrade. And if, for any reason, people suspect that 2.4.X.Y might have brought a bug, then reverting to 2.4.X.Z(Z<Y) should at most bring back older bugs but not remove previous support for any hardware. The problem with new hardware support is that it can break sensible setups :
- adding a new network card support will cause existing cards to be renumberred (it happened to me on several production systems when switching from 2.2 to 2.4)
- adding support for a new IDE controller can cause hda to become hdc, or worse, hda to become sda (problems encountered when adding libata support)
- enabling some devices might lock up memory and/or I/O address ranges on a bus leading to other devices not working anymore. I had this problem when using dlink 580 quad port nics in some buggy machines already equipped with adaptec starfire nics.
- other core devices might cause system instability without the admin being aware they're really used (eg: ACPI, ...)
Since hardware diversity is so high that nobody can know everything, I think it's better to avoid playing alone with people's hardware, but I agree it's sometimes very hard to resist.
Adrian, when you have a doubt whether such a fix should go into next release, simply tell people about the problem and ask them to test current driver. If nobody encounters the problem, you can safely keep the patch in your fridge until someone complains. By that time, the risks associated with this patch will be better known.
> > "is not really allowed under the current -stable rules" is a bit hard to > > answer, but considering that "Missing PCI id update for VIA IDE" was OK > > for 2.6.17.12 I'd say it's consistent with what you are doing. > > That was a bugfix as the driver could not access that device without > that fix.
Even this might be dangerous in late -stable releases, unless it was a recent regression.
Just my 2 cents, Willy
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |