Messages in this thread | | | From | Michael Rothwell <> | Subject | RE: Definitions | Date | Wed, 9 Aug 2000 15:42:53 -0400 |
| |
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/
| |