Date: Wed, 7 Apr 2004 17:05:16 +0200
From: Lars Marowsky-Bree <lmb@suse.de>
To: LKML Mailinglist <linux-kernel@vger.kernel.org>
Subject: Re: Rewrite Kernel
Message-ID: <20040407150516.GC23517@marowsky-bree.de>
References: <20040407125406.209FC39834A@ws5-1.us4.outblaze.com> <1081348038.5049.6.camel@redeeman.linux.dk> <200404071455.i37EtOn8000182@81-2-122-30.bradfords.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <200404071455.i37EtOn8000182@81-2-122-30.bradfords.org.uk>
User-Agent: Mutt/1.5.6i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1316
Lines: 34

Guys, gals,

you are all missing the point.

It is obvious that what we really need is a hand-optimized in-kernel
core LISP machine written in >i386 assembly, then we need to port the
rest of the kernel to run as LISP bytecode on top of that in ring1 (in
particular the security policies).

Of course, important privileged user-space such as glibc should be
ported to this highly efficient non-recursive LISP machine too for
efficiency and run on ring 2 for speed and security.

As a further benefit, this could provide us with a stable kernel binary
ABI via the LISP interfaces to which we could dynamically translate the
existing kernel modules on load, for which nvidia and the binary-only
Inifiband stack seem perfect candidates to secure industry buyin.

Oh, and of course this project needs to be managed via BitKeeper.


Sincerely,
    Lars Marowsky-Br?e <lmb@suse.de>

-- 
High Availability & Clustering	      \ ever tried. ever failed. no matter.
SUSE Labs			      | try again. fail again. fail better.
Research & Development, SUSE LINUX AG \ 	-- Samuel Beckett

-
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/