Re: Linux 2.6.16.30-pre1
- From: Willy Tarreau <w@xxxxxx>
- Date: Sat, 23 Sep 2006 06:56:10 +0200
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: Linux 2.6.16.30-pre1
- From: Adrian Bunk
- Re: Linux 2.6.16.30-pre1
- References:
- Linux 2.6.16.30-pre1
- From: Adrian Bunk
- Re: Linux 2.6.16.30-pre1
- From: Greg KH
- Re: Linux 2.6.16.30-pre1
- From: Adrian Bunk
- Re: Linux 2.6.16.30-pre1
- From: Greg KH
- Linux 2.6.16.30-pre1
- Prev by Date: Re: [BUG] i386 2.6.18 cpu_up: attempt to bring up CPU 4 failed : kernel BUG at mm/slab.c:2698!
- Next by Date: Re: 2.6.1[78] page allocation failure. order:3, mode:0x20
- Previous by thread: Re: Linux 2.6.16.30-pre1
- Next by thread: Re: Linux 2.6.16.30-pre1
- Index(es):
Relevant Pages
|
|
