Re: New dev model (was [PATCH] delete devfs)

[Adrian Bunk]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/