Re: Hurd TWiki trial - Announcement
On Tue, May 14, 2002 at 08:02:50AM +0200, Robert Millan wrote:
> very interesting. you mean like, *fs, proc and auth will be treated as
> separate components of the system? maybe there could be a package for
> each, so they can be handled/upgraded separately. does that technicaly
> make sense?
Do you consider your MTA, cron and syslogd seperate componentes of the system?
They all interoperate through well defined interfaces (MTA logs messages in
syslogd, cron sends mail, etc).
There is a reason why Hurd stands for Hird of Unix Replacing Dameons.
Because the Hurd servers are like Daemons in Unix, and all together replace
the Unix kernel. They have well defined interfaces which are guaranteed to
never change, only to be extended (and old interfaces might be discontinued,
in that case you get an error if you try to use it).
You can already plug in arbitrary filesystems and other servers into the
Hurd. You can provide your own crash server by setting CRASHSERVER
environment variable to ~/servers/crash, for example (untested ;). You
can use your own auth server (see fakeauth, for example), or your own proc
server (would be implemented similarly to fakeauth). You _should_ be able
to set your own EXECSERVER path, but this is deactiated because of security
concerns in the current implementation.
Currently, it is sometimes easier to replace _all_ system servers than just
one. The boot command does just that, it boots a second (third, fourth,
...) Hurd system where all servers (auth, proc, exec,...) run as your user,
from your own root filesystem image. But it is only a matter of
implementing a little functionality here and there to make the system more
modular, so that you can boot from an existing filesstem (directory tree,
for example), or reuse certain system servers (auth, proc, and just replace
exec and the rest), etc etc. All of this should be possible without
changing the existing interfaces of the servers, the basic functionality
required to do all of this is already in there. This is not an accident, it
was designed to make all of this possible.
And who says that this second Hurd system should be just a copy of the
original system, or a Hurd-like system at all? Ultimate flexibility would
only be achieved by putting a hardware virtualization layer below the Hurd
on top of the microkernel, though.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
--
To UNSUBSCRIBE, email to debian-hurd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: