[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.027 / U:4.308 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site