Re: Linux 2.6.16.30-pre1

[Adrian Bunk <bunk@stusta.de>]

On Sat, Sep 23, 2006 at 06:56:10AM +0200, Willy Tarreau wrote:
> 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.

Bugfixes causing regressions are much more likely than new hardware 
support adding regressions.

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

Either you want to use the newly supported hardware or you don't want to 
use it.

In any case, I don't see your point.

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

I don't consider merging any patches that could cause the sda problem.

People not using the onboard IDE controller but a different controller, 
but OTOH having the driver for their onboard controller enabled in their 
kernel really sounds like a strange case.

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

It's not that I wanted to upgrade ACPI to the latest version.

And my rules are:
- patch must be in Linus' tree
- I'm asking the patch authors and maintainers of the affected subsystem
  whether the patch is OK for 2.6.16

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

It was a case that never worked before.

> Just my 2 cents,
> Willy

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed