lkml.org 
[lkml]   [2000]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Announce] BKL shifting into drivers and filesystems - beware
Linus Torvalds writes:
>
>
> On Thu, 13 Jul 2000, Richard Gooch wrote:
> >
> > Perhaps the solution is to have shorter development cycles. Say 6
> > months before feature freeze, then a planned 3 month shakedown
> > (extended only if there are reliability problems). Part of the problem
> > is that so many new things get piled into each development series. Cut
> > back on the number of significant things per cycle (say just one or
> > two).
>
> I agree.
>
> This was what I wanted for the 2.2 -> 2.4 change too, and a much shorter
> development cycle would be wonderful. It obviously was not to be: 2.4 is
> already about 18 months out. We're not as bad as the 2.0 -> 2.2 cycle was,
> but it's painful.
>
> It seems to be a lot harder than it should be to keep short
> development releases. I certainly haven't found the magic
> combination yet. 2.4.x is definitely all I hoped for (the big goal
> for me was to make sure that the mindcraft-like web-performance
> scalability problems would be gone, and we definitely fixed that),
> but it took much too long.

Why not just shut the door on new features after 6 months? Even if
they are things you personally would really like to see (like the I/O
and networking scaling changes), if they're not ready in time, they
have to wait for the next cycle.

Looking back at 2.3.x, we see that Ingo's I/O scalability stuff went
in really early, because it was "ready" ("ready" doesn't mean safe;-).
But the networking scalability stuff (aka softnet) didn't go in until
this year. Either it wasn't ready, so should have waited for 2.5 when
the patch was more mature, or it was close enough and it should have
gone in regardless. If it's OK to break the kernel for several
patchlevels for I/O changes, it's also OK for networking changes.

If you just want to manage one significant change at a time,
particularly if it's a bit rough around the edges, wait at least a
month before applying the next major patch, to make sure the previous
one has settled down. Or wait until the next cycle.

Even after the softnet patch went in, we kept being hit by more and
more scalability patches. And multiple VFS redesigns. We didn't
*really* need all these changes to go in before 2.4.

> What would help would be more modular releases: smaller pieces of
> the kernel getting released independently, allowing for smaller and
> shorter release cycles. In Linux at least we don't have the "whole
> world" release issue that most other OS people have (including the
> free ones: I think the BSD "world" approach is horrible partly
> because of the release issues), but even just the kernel is so big
> that it would be nice to be able to see it as multiple independent
> projects.
>
> At the same time it's obviously not true that there are independent
> projects, and especially drivers (which _sound_ independent) are
> very likely to be impacted quite a lot by infrastructure
> changes. There are no really clear lines to split development up by,
> and the cures are worse than the disease ("microkernels", I hear
> somebody shout. But that approach would just make it impossible to
> do the kinds of improvements we _have_ done and probably will
> continue to do).

I don't think splitting the kernel development is the answer. Having
stuff separate is just too frustrating. I was so glad to see PCMCIA
drivers go into the kernel.

As for "microkernel". Ug. I see another flamewar coming.
PEOPLE: read the FAQ before you so much as breath that word on the
list, let alone post "well, why not?". <shudder>

Maybe you just need to get tougher with the cabal. You're pretty
hard-nosed when it comes to rejecting patches which so much as offend
your tastes (let alone those that suck). How about extending that to
timing? No matter how lovely the patch, if it's past feature-freeze,
reject it. Of course, come next cycle, said patch should go in
promptly.

Also, if there is a reliability problem somewhere, only accept patches
during feature freeze which do the minimum to fix the problem. Don't
let "bugfixes" be a back door to doing wholesale redesigns which fix
the problem along the way. Go for a surgical fix, not chemotherapy.
Too much chemo and the patient dies.

It's getting embarrasing when people ask me when 2.4 will be out. Not
only don't I know, AFAIK, nobody knows. And when of course they say
"but wasn't 2.4 supposed to come out last year, and didn't Linus want
a shorter cycle than 2.2?", I have to look away and mumble something
and hope they'll go away. Or try and change the subject. I can't keep
getting away with the brush-off. People are beginning to suspect.

Regards,

Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca

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

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.076 / U:0.756 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site