Messages in this thread | | | From | (Alan Cox) | Subject | Re: Now, why didn't we think of this before? | Date | Tue, 25 Mar 1997 21:43:16 +0000 (GMT) |
| |
> But - Linux as it stands has a few major failings: > * non-dynamic object allocation (see recent >256 fd thread for just one > example)
The fd one isnt a kernel problem paticularly, its a horrible backward compatibility worry.
> * non-re-entrant kernel
Much of it is re-entrant. Its not got in-kernel pre-emption but thats a different thing and a good choice for uniprocessor non hard real time boxes. Now we dont fit the uniprocessor non rt category its changing
> * non-threaded kernel
There is a thread for each task and a few others,
> a dynamically resizeable pool. Memory is cheap, and in many circumstances, > a well chosen algorithm will be better than just allocating enough for the > average user. For a single user box, a well chosen algorithm will use less > memory and be faster, and for a high end Internet server, with 4
Cache is expensive, cache is small, dynamic resizable objects tend to be relatively vastly slower.
> A fully threaded kernel, (for example) breaking down device drivers into > their own threads would help again, as we could schedule them on any > available processor, and be more independant of the kernel state. This > would give us a major speed boost, particularly on SMP machines.
Threads are too expensive to implement on real hardware. If you have full pre-emption the threads issue for drivers goes away. Threads are really a clean but slower representation of pre-emption. Its a semantic aid to programming not a different result.
> I'd also like to see much better boot management. The idea of an OS booting > to a textual display in 1997 is ridiculous. Also, the current boot strategy > is an all or nothing approach. If you don't make it to a login prompt, you > better have a recovery boot disk around. That sucks.
Thats not a kernel issue. And most distributions passing "s" as a boot argument drops you nicely single user. Graphical boots are a user mode issue too - write one with svgalib - its not hard, fork it from init early on, send it messages to make it light up different things, even lets you alt-f1 back to the text console. When its booted start xdm in your rc files and off you go.
As to 2.1 turning into 2.2 the SMP changes are a long way from done and there is much networking stuff to be done. Also for that matter merges of M68K, ARM and MIPS code to be sorted.
Alan
| |