lkml.org 
[lkml]   [2005]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: what's next for the linux kernel?
    On Thu, Oct 06, 2005 at 05:53:40PM -0400, Michael Concannon wrote:

    > I think someone already mentioned that the issue is that the delta
    > between an idealized NT registry (which has a few notable hurdles - see
    > above) and what we have to day is simply a matter of "KISS". What do
    > you gain from complicating the system that cannot be gained with
    > visualization tools on top of what is there?

    it is advocated that storing data in text format is easier
    to recover with a minimum of tools.

    if, as todd sabin's driver shows, you can present the binary data via a
    text-editable filesystem driver, then even _that_ argument goes away.

    > Someone wants XML in /proc? Well, that's just fabulous they can write a
    > virtual filesytem that accomplishes that on top what is there and leave
    > the rest of us out of it :-) If what they do becomes indespensible for
    > a critical mass, then even better, we mount "xmlprocfs" in our future
    > systems and are fat dumb and happy.

    reiserfs already has had an XML plugin written for it, which resulted
    in the person it was written for thanking the author for writing the
    "best xml database they had ever seen".

    think structured storage and streams (which NTFS used to support, and
    which explorer.exe in nt 3.51 used to support before
    bill/someone-on-high ordered it to be taken out) and now apply that
    principle to XML instead.

    > Back to your original point which seemed to be, at least to me, to try
    > to re-evaluate the portioning problem between
    > Hardware/Software/Drive/OS/User/Threads.

    yes. seems like ages ago.

    > I agree, that the system
    > appears to be strained and chaotic with all OSes chasing an ever
    > increasing and impossibly large array of hardware and all-the while the
    > future is even more complex as it seemingly must be a heavily
    > parallelized future to compensate for the "end of Moore's law".

    what - the constantly revised one, or the original one?

    > Given
    > the hardware in question, though, I am not sure I that I see that Linux
    > should go to micro-kernels to solve the problem...

    i would be delighted to see #ifdef HAVE_L4_MICROKERNEL #endif in the
    linux source code.

    AS AN OPTION.

    that people could choose "bugger that damn l4 trash" or "bugger that
    monolithic trash" as they see fit.

    and the l4linux source code _is_ there for the linux kernel developers
    to pick up and incorporate.

    that they have not chosen to do so - even though it is GPL code -
    leaves me a little puzzled.



    > <rant>
    > It seems to me that the driver for "correcting" this is actually closer
    > to the hardware side... I am flabbergasted as a hardware engineer that
    > at this point in time with the time elapsed between today and the first
    > PCs that things have evolved so little...

    ah _ha_.

    as a hardware engineer, what would _you_ like to see a
    modern parallel processor design have - that linux for that
    hardware would have an easy job of knocking the stuffing
    out of anything remotely attempting to come close to it?

    i.e. if you could have the proverbial cart before the
    proverbial horse, and could make decisions about the DESIGN
    of hardware - all of it - BEFORE it was dumped in your lap
    and you were basically impicitly told "we're giving you
    this for free and taking advantage of your willingness to go
    'cool hardware! let's make it run linux".


    we've already had one suggestion: a CAS-n instruction (a SIMD
    compare-and-store) which can, according to the person who kindly
    suggested it, be used for managing doubly-linked lists.

    anyone got any more?

    want to send them to me, and i will summarise to those people that
    express an interest.

    [i _so_ want this thread to die].

    > The same applies to the x86 instruction set - waded through that beast
    > (well all N volumes of it) recently? WTF?

    even _decoding_ the x86 instruction set, due to the massive
    number of exceptions / extensions, introduces significant
    instruction latency.

    a large amount of an x86 compatible processor is spent
    translating that crap into a simpler _internal_ microcode set
    of instructions.

    unberfrigginlievable.

    oh, these instructions are too slow. _let's_ go an' add multimedia
    extensions. *noooooooo.*

    --
    --
    <a href="http://lkcl.net">http://lkcl.net</a>
    --
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-10-07 00:27    [W:4.644 / U:0.640 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site