Re: hurd does NOT need /hurd
On Wed, 22 May 2002, Emile van Bergen wrote:
> > On Wed, May 22, 2002 at 04:43:44PM +0200, Emile van Bergen wrote:
> > > I'm essentially asking the question: are those 'normal' programs indeed
> > > normal programs, in the sense of some image that is loaded or mapped
> > > into a separate address space, specifying a single point of entry (being
> > > allowed to register other rendezvous points only subsequently), or are
> > > translators something else in that respect?
> >
> > They are ELF executables.
>
> Well, duh. But you probably mean that in the stricter sense, i.e. a
> plain ELF executable that only specifies its single ELF starting point.
Well, if the hurd has retained the traditional microkernel design, what
they call a translator really is just an ordinary process, like any other.
The only distinction is that it has an IPC connection (this is what a port
essentially is in mach) to whatever is managing the filesystem namespace,
so requests for it's section get routed to it.
It sounds like with HURD the only way to get the IPC connection is to
have another process (perhaps with more privilage?) create it.
In every other MK system I've used these sorts of IPC connections could be
created by a process on it's own. So for instance on QNX you could just go
'Fsys.ext2 /dev/... /mnt/foo &' and it would make it's own arrangements
with the namespace manager to own /mnt/foo.
Anyhow, just to chime in - other MK Os's like QNX and NTO keep their
'special' processes (filesystems, TCP/IP, drivers, etc) in /[s]bin or
/usr/[s]bin. Most of the time mount or other front ends will exec them
for the user, but you can run them on their own if you really want to.
Jason
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: