Re: Hurd limitations
On Mon, Feb 26, 2001 at 04:16:35PM +1100, Brian May wrote:
> Hello,
>
> I have noticed several limitations with Hurd, that occur because
> it is totally different to Linux. I am wondering what long term
> solution, if any, if proposed to get around these:
>
> - non-root filesystems not checked on startup.
> Reason: no way to tell what filesystems exist, apart from /.
If you mean non-root = user, that's true, but I doubt you mean it. If you
mean fs's apart the root fs `/', then adding them to fstab and setting the
check flag accordingly will work, just as under Linux.
> - task packages, like task-devel-common and task-debian-devel do not
> install.
> Reason: strace wont work on the Hurd. (not sure about fakeroot).
strace is a linux specific tool, a similar tool would be quite useless on
the Hurd, because little functionality is available with syscalls to the
Mach kernel. You could keep track of the messages sent at a very basic
level, but we have rpctrace to do just that in a better way.
It should be possible to make fakeroot work if it doesn't already out of the
box. I think the reason that prevented me from looking at it was that the
build process required getopts from util-linux, and I hadn't made a crufty
util-linux package back then. I would encourage you to try it.
It's quite easy: task devel packages suffer from similar linuxisms as other
packages depencies.
> - multiple mount-points (new feature of Linux). Is this possible on
> the Hurd? (I doubt it...)
Well, you can use the same source for several translators, but they will
conflict and scribble over each other or not recognize changes where it
overlaps with cached pages. But what we imagine is a much better solution,
called shadowfs (it's similar to unionfs in BSD), where you can layer
several filesystems over each other. One way to use shadowfs would certainly
be to layer an existing directory tree (or a distinct part of it) into the
shadow filesystem. This is a more generic approach, and much more useful
than just to be able to mount one filesystem several times. It's also not
implemented yet :)
I think it might be quite easy to get the linux feature you describe, though.
You just need to make a filesystem server advertise itself on a different node
than its root node, too. Look at how the tunnel interface is set up in
pfinet. It sets itself as the translator for /dev/tunX. From this moment,
pfinet serves requests at /dev/tunX, /servers/socket/2 and all sockets to
it. Now, pfinet does different things on each of these, but it would be even
easier to do exactly the same thing on two translated nodes.
If you'd really want this feature in a filesystem, you'd add another RPC
which would tell the filesystem server to set itself as the translator on a
certain node. (Or just pass the port directly). But I don't think it is too
useful a feature. What's the difference between mounting several times and
just setting symlinks? [1] [2]
So, in short: The feature you describe could be easily implemented in the
Hurd. It would be an optimization of a specific symlink, the symlink to the
root node of the filesystem, with the extension that it would probably work
where a symlink wouldn't because of permissions (for example chroot,
probably. I am not sure). A more generic approach, shadowfs, is much more
useful.
Thanks,
Marcus
[1] In Linux, you don't get "sub mounts", in fact, there is nothing like a
submount in linux. In the Hurd, you would always get the "submounts". To not
get them, you'd need to take special precautions, and it would be quite
impossible to do this cleanly, because even symlinks might just be
implemented as translated nodes (see "showtrans /usr" for a faked example).
[2] A symlink forwards a request to the other filesystem, while in the more
direct approach, this middle man would be eliminated.
--
`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
Reply to: