Re: what's next for the linux kernel?
From: Luke Kenneth Casson Leighton (lkcl_at_lkcl.net)
Date: 10/07/05
- Previous message: Jiri Slaby: "Re: [PATCH 5/10] drivers/char: pci_find_device remove (drivers/char/specialix.c)"
- In reply to: Michael Concannon: "Re: what's next for the linux kernel?"
- Next in thread: Michael Concannon: "Re: what's next for the linux kernel?"
- Reply: Michael Concannon: "Re: what's next for the linux kernel?"
- Reply: Michael Concannon: "Re: what's next for the linux kernel?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 6 Oct 2005 23:24:39 +0100 To: Michael Concannon <mike@concannon.net>
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> -- - 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/
- Previous message: Jiri Slaby: "Re: [PATCH 5/10] drivers/char: pci_find_device remove (drivers/char/specialix.c)"
- In reply to: Michael Concannon: "Re: what's next for the linux kernel?"
- Next in thread: Michael Concannon: "Re: what's next for the linux kernel?"
- Reply: Michael Concannon: "Re: what's next for the linux kernel?"
- Reply: Michael Concannon: "Re: what's next for the linux kernel?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
