Re: fakeroot inquiry

[Marcus Brinkmann <marcus@gnu.org>]

On Fri, May 03, 2002 at 04:55:59PM +0200, Niels M?ller wrote:
> > 1) Subhurds suck for connecting to a network
> 
> I hope there's no hard reason for that. It ought to be possible to set
> up some bridging (similar to what vmware does between host and guest
> os).

No, of course not.  The main reason is that two Hurds (we don't call
them subhurds anywmore, they are more peer than parent/child, you might
call them neighbourhurd) are too isolated :)  they are really two
distinct Hurd systems running in parallel, and the only connection is
that the second Hurd gets a faked master device port so when it opens
"console" it gets a faked console device.

> But sure, that's a project for the future. Having the parent hurd
> provide a "fake" device port for the subhurd to use, not giving it
> direct access to the real Mach device port, would be a start, I guess.
> But I'm mostly ignorant about Mach device access.

Well, you could fake an ethernet card, eth0 if you want.  Another way
is to allow some bindings between the two Hurds, eg when looking up
/servers/socket/2 in the one Hurd, you are really looking up the one
in the other Hurd.  This is a firmlink, and the only problem is getting
the root filesystem ports exchanged.

But that is only part of the story.  I would like to be boot more
flexible, in that you can use an already existing filesystem to boot
another Hurd.  This involves faking out that part of the bootstrap
protocol that is usually done by the root filesystem, and maybe
someothing with the auth server.  This would allow
for a boot to be more like a chroot, very useful IMO if you only want to
debug auth, init, proc or exec.  And of course, it would be even better
if you could fine tune which components get booted, and which gets
reused.  Like, say,  you only want to replace proc, exec, and do a
chroot to test a new process handling system.

The Hurd can do all that conceptually, but some glue stuff is missing
here and there to really do it.

Thanks,
Marcus


-- 
To UNSUBSCRIBE, email to debian-hurd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org