Messages in this thread | | | From | Alan Cox <> | Subject | Re: Ok, making ready for pre-2.4 and code-freeze.. | Date | Tue, 14 Dec 1999 21:04:01 -0500 (EST) |
| |
> loopback, ramdisk, raid - more or less broken.
Ingo has raid and PIII diff merging queued to do. The old raid code isnt worth fixing on that basis.
> CODA - will need serious testing after the expected large patch.
CODA is the sort of thing that can be fixed up later.
> procfs - needs decision on namespace policy/namespace rework. And > proper dealing with races on module offloading, but that's old story.
We have a ton of other user exploitable races with module load/unload including basic stuff like open which with a bit of care you can use to crash the machine as any user. Procfs is only a part of this.
Taking my working list the key items seem to be
About 70% of device drivers dont have the setup code fixed. In many cases that makes them unusable non modular About 1/3rd of the ISA device drivers using memory mapped IO are still broken AF_UNIX sockets are broken, and there are numerous IP layer bugs only fixed in DaveM's trees that have to be fixed, either by extracting them or going softnet. The SPX sockets are totally broken The PIII/Athlon/K6/Pentium memcpy etc acceleration code needs merging NCR5380 is broken for SMP AHA152x is broken for SMP Anyuser can crash the code due to module races (eg open) RAID 0.90 needs merging Vmalloc needs to take flags for DMA optionally (for 32bit PCI scatter gather) Getblk/mark buffer races in most file systems Protection for inode size fields is wrong right now
Less critical stuff Switching to the new i2c code core and the new bttv driver. Affects only some tv cards so is ok Per process rt signal queue limits Syncppp should use the new generic ppp code Back merge 2.2.13/2.2.14 fixes
I have the i2c stuff sorted mostly (thanks to Gerd and co), the 2.2.13/14 stuff I will do next week and is all bug fixes, Im still trying to stomp all the isa memory mapped I/O issues. I'll also sort the vmalloc cases out.
Most of the above is bug fixing or driver stuff so is post freeze work. The raid and PIII stuff are not. I'd also prefer you to look at the core softnet changes and say yes/no, then draw your line the side of it you choose. The softnet work is the other 50% of the scaling work, without it 2.4 wont scale much better than 2.2 for real world situations. That bothers me.
I've got a list of other stuff (Erez stackable fs, telephony API work, performance counters, lm-sensors, ibcs) that are in the nice but so be it category. I have no problem with those landing outside of 2.4.0 or staying as add ons. Skipping softnet though would I think be a mistake.
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/
| |