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 [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
