[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Porting the Hurd to VK (Was: running hurd in linux)

From: Adam Olsen
Subject: Re: Porting the Hurd to VK (Was: running hurd in linux)
Date: Mon, 13 Aug 2001 09:08:56 +0000
User-agent: Mutt/1.3.18i

On Mon, Aug 13, 2001 at 02:56:50AM +0200, Farid Hajji wrote:
> > > I think the idea is rather to run Linux with Hurd. For instance you
> > > could boot something like a MkLinux single server under gnuMach
> > > and connect it to ethernet1, com1, tty1, etc, and then also have a
> > > Hurd login on the console.
> > Porting GNU/Hurd to run on top of a virtual kernel (VK) would provide
> > exactly this kind of advantage. Basically, you'll be able to boot the
> > virtual uKernel, either on top of Mach, L4 or even as a server/library
> > on top of Unix. Then, you could boot the Hurd on top of this VK.
> [snip]
> Of course, the other way around as you suggested (MkLinux server on top
> of GNUmach besides the Hurd servers) is also possible. One big problem
> here is how to coordinate access to Mach devices. This is exactly the
> same problem than you face when you run a sub-hurd parallel to the Hurd.
> As long as you use different devices, it should be okay, but as soon
> as you need to access shared devices, things get hairy. Devices with
> likely contention are hd's (even if you use different partitions),
> com? and I/O.

I think the solution here is that all device access should be done
through hurdish interfaces.  Only the parent would have real access to
the mach devices.  The subhurd would have to have access given to it,
eg via mach ports.  This also contributes to portability, since you'd
have defined interfaces for the device drivers to export.


Adam Olsen, aka Rhamphoryncus

reply via email to

[Prev in Thread] Current Thread [Next in Thread]