Re: kernel changes

From: bill davidsen (davidsen@tmr.com)
Date: Wed Oct 03 2001 - 19:36:01 EST


In article <07f901c148b8$720a6230$1a01a8c0@allyourbase> dmaas@dcine.com wrote:
| > The answer is to treat all linus/ac/aa/... kernels as development
| > kernels. Don't treat anything as stable until it's been through
| > a real QA cycle.
|
| I definitely have to second what you guys are saying here... 2.2.x is the
| stable kernel series, 2.4.x is for caffeine-fueled developers who read the
| LKML at least once every day...

  Not really. I have found that 2.4 kernels are usefully stable if you
pick them carefully.

| e.g. I consider it extremely embarrassing that fundamental drivers like
| aic7xxx, emu10k1, tulip, etc. are breaking regularly in the mainline
| kernels. I haven't had any trouble with things like this in Windows for
| several years now... Sure the Windows drivers are probably a few percent
| slower, but as Nathan Myers once wrote, "It is meaningless to compare the
| efficiency of a running system against one which might have done some
| operations faster if it had not crashed."

  Again, given the choice of the o/s failing every few months or not
using your hardware, where do you go? I haven't found a 2.2 kernel which
like running multiple NICs at 85% of max most of the time, while several
of the 2.4.kernels, most recently 2.4.6 will.

| I think we all owe major thanks to Alan Cox, who does his best to keep the
| house in order amidst the chaos of kernel development (kudos to Mr. Cox for
| holding on to Rik's VM design long enough for it to stabilize!). If anything
| I wish there were a third primary maintainer who would take an even more
| conservative stance, hanging maybe 2 minor versions behind Linus and -ac,
| and only picking up changes that have been tested widely. Hmm, the people
| working on distro kernels are probably just about doing this already...
| Maybe if they could combine efforts somehow?

  A quick look at the c.o.l.development.system will show I said ages ago
that we should QA "stable" kernel releases before sending them out. I
offered to set up a group to do that for each release candidate, but
there was no interest.

  The VM work is really needed, but I wish the development was in "pre"
kernels, not releases. I've been playing while on vacation, and
2.4.9-ac14 looks much better, 2.4.9-ac16 has minor problems on a machine
I won't see until I "get back to work," and I haven't deceded if I want
to try 2.4.9-ac18 or not. Sadly, horror stories on 2.4.10 have suggested
that I let others try that.

  Given the load of totally new VM stuff dropped in, I admit I'd like to
see useful stuff which only takes effect if configured (the so-called
Athlon patch) in the kernel, since many systems simply will not run an
Athlon kernel without it. I only wish the preempt was being pushed as
hard as VM, it looks really good on loaded machines.

  Perhaps it's time for 2.5 indeed.

-- 
bill davidsen <davidsen@tmr.com>
 "If I were a diplomat, in the best case I'd go hungry.  In the worst
  case, people would die."
		-- Robert Lipe

- 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/



This archive was generated by hypermail 2b29 : Sun Oct 07 2001 - 21:00:29 EST