Re: ABI-changing kernel security fixes for sarge
On Wed, 23 Mar 2005 19:27:20 +0000, Matthew Wilcox wrote:
> On Wed, Mar 23, 2005 at 04:09:42PM +0100, Frank Lichtenheld wrote:
>> How big is the chance that we will have another ABI change during
>> sarge's lifetime (100%?). So it can't hurd to figure out the problems
>> with that now independently of our decision in this matter...
> Absolutely. It's bound to happen again. We also need to figure out
> how to do driver updates during sarge's lifetime. I suspect virtually
> everybody has had the experience of trying to install woody on a new PC.
> Some of the problems I remember:
> - new PCI IDs for the eepro100 driver
> - i830 chipset not supported (also needed new X)
Unfortunately, a driver update is rarely the case of simply adding new PCI
IDs. They usually end up updating some random register poking, which is
done because of some errata that's NDA'd or sitting on some nameless
webserver in .tw somewhere. I have come to fear those sorts of updates,
because a) I typically don't have the hardware available to me, and b)
people don't report bugs, so if the update ends up being a regression for
some bit of hardware, the kernel team doesn't find out about it for a
while, and c) when we do find out about a regression, getting people to
test new drivers is a long and drawn out process (w/ lots of folks using
the hardware in production, so they're unable to test).
OTOH, I have hardware that's already not supported by sarge (VIA video
chipset that's only supported by xorg). As much as the security team is
loathe to support multiple kernels, it does seem like having multiple
kernels in d-i is the safest way to support this sort of thing. We get
this for free in sarge, by having 2.4 and 2.6 kernels. In the future, it
might be worth having multiple 2.6 kernels, or decoupling drivers from
core kernel stuff (core kernel stuff is generally fairly easy to see
regressions in, so there's no need to have multiple version of that).
Does d-i have an option to insert a driver disc (floppy or
> ability to grab a new module package from the net (suboptimal as it may
> be the network driver that's missing)?
This will be something that's desirable for kernel-source-nonfree, in the
future, as well.
> Either that, or we need to commit to a 6-month release
goal for etch and
> future releases. Which wouldn't suck, we used to do it...
> Buzz (1.1): June 1996
> Rex (1.2): December 1996 (6 months)
> Bo (1.3): June 1997 (6
> Hamm (2.0): July 1998 (13 months)
> Slink (2.1): March 1999 (9 months)
> Potato (2.2): August 2000 (17 months)
> Woody (3.0): July 2002 (23
> Sarge (3.1): ? (32 months and counting)
Of course, 6-month release cycles would be the ideal situation. It's much
easier for people to try different versions of distributions for hardware
compatibility, versus reading documentation on d-i, passing in various
kernel and boot args, loading different versions of drivers, etc. This
isn't an option for most people currently, since woody is so stale.