[lkml]   [1997]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Now, why didn't we think of this before?
> 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.


 \ /
  Last update: 2005-03-22 13:39    [W:0.071 / U:1.572 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site