Subject: Re: Rewrite Kernel
From: Redeeman <lkml@metanurb.dk>
To: LKML Mailinglist <linux-kernel@vger.kernel.org>
In-Reply-To: <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>
	 <20040407150516.GC23517@marowsky-bree.de>
Content-Type: text/plain; charset=iso-8859-15
Message-Id: <1081358490.4927.14.camel@redeeman.linux.dk>
Mime-Version: 1.0
Date: Wed, 07 Apr 2004 19:21:30 +0200
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1336
Lines: 35

On Wed, 2004-04-07 at 17:05, Lars Marowsky-Bree wrote:
> 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.

this is a good idea, but i doubt that anyone would dare to do that :D
> 
> Oh, and of course this project needs to be managed via BitKeeper.
> 
> 
> Sincerely,
>     Lars Marowsky-Br?e <lmb@suse.de>
-- 
Regards, Redeeman
redeeman@metanurb.dk

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