Time for a Linux Bug-Fixing Cycle

AlanS2002 writes "As reported here on Slashdot last week, there are some people who are concerned that the Linux Kernel is slowly getting buggier with the new development cycle. Now, according to Linux.com (Also owned by VA) Linus Torvalds has thrown his two cents in, saying that while there are some concerns, it is not as bad as some might have thought from the various reporting. However he says that the 2.6 Kernel could probably do with a breather to get people to calm down a bit."

Comments

Really now.

[bluefoxlucid]

A few comments have flown already, but let's be sane here and examine microkernelism.

File system crashes. Microkernel is going to panic because there's no way in hell it can guarantee consistency with running processes now; the FS driver might log-replay or FSCK, but all open file handles become invalid (this can be reduced though...). A monolith is also going to panic; the driver may be in a kernel thread and get flushed and re-initialized, but same problem with file handles.

IDE driver crashes. Microkernel can block disk reads, bring it back up and hold the file system's state, re-flush buffers that weren't confirmed, unblock disk reads. Monolyth may do the same if the driver is in a separate kernel thread.

Sound driver crashes. Microkernel re-inits it. Monolyth re-inits the thread if it wants to (Linux just says it's broke and sound stops working).

Video crashes. Hardware needs a re-initing. Microkernel means X gets killed! Monolyth means X gets killed! Although the video driver CAN be re-initialized, Linux is likely to panic; MULTICS was easily 70% error recovery code, UNIX we just had this routine called panic() where you yell down the hall to reboot it...

Network crashes. Our entire TCP/IP stack is blown out. Microkernel re-inits it, monolyth can too, most likely we let it die and you reboot. We got tired of panic()ing for simple shit, we call this "Oops."

What a microkernel DOES have that's nice is the ability to quickly and easily ensure that drivers with fucked up code don't stomp all over other kernel memory. I suppose some MM hacks can be done to remove writability but..

What Linux really needs is the 2.6 model for odd series, as "Volatile," on a set even "Stable" series release cycle where "Volatile" is pinned as "Stable." That way the "Volatile" is always as usably stable as 2.6 is now, while "Stable" is concrete. Everybody happy and no silly 2.6.x.y running trees.