Re: Linux 2.6.16.30-pre1

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages