I have a question somewhat related to the "bug fix" vs "new feature" debate.
I agree that new drivers than can be moduled-out can be included w/o a
problem. However, Linux 2.3.x/2.3-99pre/2.4-test/etc has been very
unpleasant to program for due to its instability -- interfaces change, scsi
drivers don't even compile for sparc, it crashes pretty regularly, etc. Far
too many releases over the past year (since 2.3.99 started) have changed
something fundamental. Is there any way to make a real estimate as to when
Linux 2.4.0 will be done, stick a fork in it, it's not mutating anymore?
There seems to be little real control or guidance from the top (no slight
intended; just an observation); please correct me if I am wrong. I hope I am
wrong. But how will it come to pass that 2.4.0 stabilizes, enters an honest
bug-fixing stage, and is prepared for release? We have spent most of our
effort keeping up with various changes in the kernel rather than pushing our
software forward during the last few months. I have considered cancelling
the Linux 2.4 version until 2.4 stabilizes, and back-porting to 2.2.16
instead. But that involves a fair amount of pain as well; 2.4 provides some
needed improvements. I've thought about using NetBSD instead. But I would
really like to finish it on Linux, because that's where we started it.
Michael
-----Original Message-----
From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
Sent: Wednesday, August 09, 2000 2:52 PM
To: zapman@homer.interlan.net
Cc: linux-kernel@vger.rutgers.edu; zapman@interlan.net;
rothwell@interlan.net
Subject: Re: Definitions
I dont think there is a simple answer
Clear bug fixes
o if I do this it crashes the kernel. This patch stops it
o if I do this it violates the standard
Clearly new stuff
o New file system
o Rewriting the VM
o Adding all the flash device support
Now of the new there are three categories:
1. A driver or file system or protocol stack using existing interfaces
that
makes no change to the rest of the kernel. If turning the module
otpion
off gives a kernel that has no changes then this is good.
These kind of things can be added almost any time as they dont
impact
stability for anyone else and a bad driver is generally better than
no support
2. Stuff that tweaks internals a bit (extreme case rewriting the VM).
You get it wrong and everyone gets crashes. Has to be done with care
well tested and preferably earlier in the cycle
3. Changing the interfaces themselves and breaking all drivers or all
file systems. This should be done early. Some of Al Viro's stuff
was late (but probably wise in the long term) and this caused a fair
bit of friction
Alan
-
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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:19 EST