Messages in this thread | | | Date | Fri, 23 Jul 2004 01:25:41 +0200 | From | Adrian Bunk <> | Subject | Re: New dev model (was [PATCH] delete devfs) |
| |
On Thu, Jul 22, 2004 at 03:28:39PM -0700, Paul Jackson wrote:
> > There's much worth in having a very stable kernel. >... > Now, I repeat, this is at the head end. End users who want stability > aren't feeding directly off kernel.org anyway.
It depend on your definition of "end users" and "stability".
You might be right for people buying for many $$$ distributions with support to run Oracle on it.
But I know many people who run ftp.kernel.org kernels on many workstations and small servers e.g. in universities.
> The affect downstream on real users is this. If the head end operates > in big chunky style, then as this big change flows downstream, it makes > transitions for distros, service providers and middlemen more costly and > difficult, creating expenses that must be passed on to the end user.
Currently there's one transition to a new major release of the kernel every few years. You wait until a new major release of the kernel has matured, test whether both the transition and the new kernel work, and update the kernel.
An update to a new minor version of the kernel was until now relatively cheep since breakages that require further investigation were relatively seldom.
And what happens if you are a distribution, kernel 2.6.15 is the current kernel containing many important updates, but $nontrivial_feature added in 2.6.10 broke $architecture your distribution supports. This means you have to support both kernel versions with security updates creating expenses that must be passed on to the end user.
I vaguely remember such issues in the past like DECstation support was broken since 2.4.20, and some m68k subarchs that were at least until recently not working in any kernel more recent than 2.2 .
Such breakages might occur more often in the future during a stable series.
> Yes - damming up the flow of changes creates stability. But if you're a > middleman, you don't need Linus to choose where to build the dam, and > when to open the flood gates. It's more efficient for you to choose for > yourself when to do that damming, based on your particular resources and > customer needs, rather than have to deal with hundred year floods and > draughts imposed on you by Zeus. > > The end user always gets their stability, if only because they won't > upgrade a system that is "working".
How do such end users get security updates?
> And every change at the head end is disruptive for some poor slob. > The only perfectly compatible change is no change at all. We delude > ourselves if we think we can separate the "safe" fixes and additions > from the "unsafe" incompatible changes. Better that we should expend > some energy on smoothing out and minimizing the cost of change to those > downstream from us. This needs to be done the old-fashioned way, one > change at a time. > > The question is whether we impose, on all those downstream from us, > occasional hundred year floods, or do we provide a steady stream, and > let them build their own little beaver dams, as suits their various and > diverse needs and business cycles. >...
But what to do if some part of the kernel (let's call it "XFS") has some problems (let's call it "Oops") with a new feature (let's call it "4kb stacks on i386") introduced in a kernel during a stable kernel series (let's call it "2.6.6") and this isn't fixed by the maintainers (let's call them "SGI") for some time (let's call it "until now")?
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |