Anyone working on the Microkernel implementation
of Linux? Specially in the area of seperating the process
and the file management activities out of the kernel.
Rakesh.
On Mon, Feb 25, 2002 at 11:11:59PM -0700, Rakesh Kumar Banka wrote:
> Anyone working on the Microkernel implementation
> of Linux? Specially in the area of seperating the process
> and the file management activities out of the kernel.
Not if they learned from history, they aren't. But the Hurd could use
your help, they're a microkernel.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
this is a FAQ
basicly it boils down to the fact that Linus believes that a microkernel
ends up spending to much of it's time formatting messages for other pieces
of itself instead of doing the work you purchased the computer to do.
David Lang
On
Mon, 25 Feb 2002, Rakesh Kumar Banka wrote:
> Date: Mon, 25 Feb 2002 23:11:59 -0700 (MST)
> From: Rakesh Kumar Banka <[email protected]>
> To: [email protected]
> Subject: Monolithic Vs. Microkernel
>
>
> Anyone working on the Microkernel implementation
> of Linux? Specially in the area of seperating the process
> and the file management activities out of the kernel.
>
> Rakesh.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Tue, 2002-02-26 at 01:11, Rakesh Kumar Banka wrote:
>
> Anyone working on the Microkernel implementation
> of Linux? Specially in the area of seperating the process
> and the file management activities out of the kernel.
>
> Rakesh.
AST? ;-)
(Sorry, that joke is based on 1991 material)
Hello,
at least two teams work upon it here in Germany
references:
http://os.inf.tu-dresden.de/index.xml.de
http://i30www.ira.uka.de
A branch of stable kernels upon L4/Fiasco is maintained at TU Dresden
and available at:
http://os.inf.tu-dresden.de/L4/LinuxOnL4/.
Though Mr. Torvalds seems not to be amused about micro kernel aproach,
this work is not done in vein due to the inherent technical superiority
in certain applications mostly regarding distributed systems including
NUMA architectures.
best, Hans Adams
> On Mon, Feb 25, 2002 at 11:11:59PM -0700, Rakesh Kumar Banka wrote:
> > Anyone working on the Microkernel implementation
> > of Linux? Specially in the area of seperating the process
> > and the file management activities out of the kernel.
>
> Not if they learned from history, they aren't. But the Hurd could use
> your help, they're a microkernel.
There are several Linux on microkernel implementations around, thankfully
using something that can really be called a microkernel. With the "we
want to run 10,000 copies of Linux on a box" market boom it may well prove
to have a practical use one day - as well as the security partitioning one
which some people overlook (and paranoid security people often do not mind
a small performance hit)
Alan
On Mon, 25 Feb 2002, Rakesh Kumar Banka wrote:
> Anyone working on the Microkernel implementation
> of Linux? Specially in the area of seperating the process
> and the file management activities out of the kernel.
You have to remember that the source code for Linux is available.
This means we can have all the advantages of modularity at the
source level without needing any of the potential disadvantages
of modularity at the binary level.
regards,
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
Hi!
> > Anyone working on the Microkernel implementation
> > of Linux? Specially in the area of seperating the process
> > and the file management activities out of the kernel.
>
> You have to remember that the source code for Linux is available.
>
> This means we can have all the advantages of modularity at the
Not *all* of them. On vsta, you could do
( killall keyboard; sleep 1; keyboard ) &
to change your keymap. On linux you need special tools for managing
modules and are not protected from module bugs. Try developing filesystem
on production box.... You can do that on u-kernels.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
On Mon, 4 Mar 2002, Pavel Machek wrote:
> Not *all* of them. On vsta, you could do
>
> ( killall keyboard; sleep 1; keyboard ) &
>
> to change your keymap. On linux you need special tools for managing
> modules and are not protected from module bugs. Try developing filesystem
> on production box.... You can do that on u-kernels.
Userland filesystems != microkernel.
On Mon, 4 Mar 2002, Pavel Machek wrote:
> > This means we can have all the advantages of modularity at the
>
> Not *all* of them. On vsta, you could do
>
> ( killall keyboard; sleep 1; keyboard ) &
How is that different from the following ?
(rmmod keyboard ; sleep 1 ; modprobe keyboard)
[no, no need to talk about hardware access ... vsta's keyboard
driver also has hardware access]
regards,
Rik
--
Will hack the VM for food.
http://www.surriel.com/ http://distro.conectiva.com/
le mar 05-03-2002 ? 22:04, Rik van Riel a ?crit :
> On Mon, 4 Mar 2002, Pavel Machek wrote:
>
> > > This means we can have all the advantages of modularity at the
> >
> > Not *all* of them. On vsta, you could do
> >
> > ( killall keyboard; sleep 1; keyboard ) &
>
> How is that different from the following ?
>
> (rmmod keyboard ; sleep 1 ; modprobe keyboard)
>
> [no, no need to talk about hardware access ... vsta's keyboard
> driver also has hardware access]
killall works when keyboard is deadlocked, I suppose.
In article <[email protected]> you wrote:
> modules and are not protected from module bugs. Try developing filesystem
> on production box.... You can do that on u-kernels.
Well, I agree that debugging get's easier if you do not crash your box every
now and then. But on the other hand... who is developing on production boxes?!
Is that usual suse policy? :)
Greetings
Bernd
Hi!
> > > This means we can have all the advantages of modularity at the
> >
> > Not *all* of them. On vsta, you could do
> >
> > ( killall keyboard; sleep 1; keyboard ) &
>
> How is that different from the following ?
>
> (rmmod keyboard ; sleep 1 ; modprobe keyboard)
>
> [no, no need to talk about hardware access ... vsta's keyboard
> driver also has hardware access]
Standart tools for standard tasks. And if there's while(1); in VSTa's
keyboard handler will not prevent killall.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
Hi!
> > Not *all* of them. On vsta, you could do
> >
> > ( killall keyboard; sleep 1; keyboard ) &
> >
> > to change your keymap. On linux you need special tools for managing
> > modules and are not protected from module bugs. Try developing filesystem
> > on production box.... You can do that on u-kernels.
>
> Userland filesystems != microkernel.
Yep, but microkernel => userland filesystems ;-). Anyway, they *can*
do things linux can't do (or linux has hard time with), like
partitioning physical machine into few logical ones, filesystems in
userland, ability to debug drivers on production machines, etc.
I like those features, but I'm not sure if costs introduced by
u-kernels are worth it.
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa