Re: Hurd limitations
>>>>> "Marcus" == Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
>> - non-root filesystems not checked on startup. Reason: no way
>> to tell what filesystems exist, apart from /.
Marcus> If you mean non-root = user, that's true, but I doubt you
Marcus> mean it. If you mean fs's apart the root fs `/', then
Marcus> adding them to fstab and setting the check flag
Marcus> accordingly will work, just as under Linux.
Ok.
>> - task packages, like task-devel-common and task-debian-devel
>> do not install. Reason: strace wont work on the Hurd. (not
>> sure about fakeroot).
Marcus> strace is a linux specific tool, a similar tool would be
Marcus> quite useless on the Hurd, because little functionality is
Marcus> available with syscalls to the Mach kernel. You could keep
Marcus> track of the messages sent at a very basic level, but we
Marcus> have rpctrace to do just that in a better way.
Thats what I thought.
Marcus> It should be possible to make fakeroot work if it doesn't
Marcus> already out of the box. I think the reason that prevented
Marcus> me from looking at it was that the build process required
Marcus> getopts from util-linux, and I hadn't made a crufty
Marcus> util-linux package back then. I would encourage you to try
Marcus> it.
I can't get either sudo or fakeroot to work.
sudo: won't accept my root password.
fakeroot: requires g++ which in turn requires libstdc++2.10-dev, which
doesn't seem to be compiled yet.
Marcus> It's quite easy: task devel packages suffer from similar
Marcus> linuxisms as other packages depencies.
Solutions?
>> - multiple mount-points (new feature of Linux). Is this
>> possible on the Hurd? (I doubt it...)
Marcus> Well, you can use the same source for several translators,
Marcus> but they will conflict and scribble over each other or not
Marcus> recognize changes where it overlaps with cached pages. But
Marcus> what we imagine is a much better solution, called shadowfs
Marcus> (it's similar to unionfs in BSD), where you can layer
Marcus> several filesystems over each other. One way to use
Marcus> shadowfs would certainly be to layer an existing directory
Marcus> tree (or a distinct part of it) into the shadow
Marcus> filesystem. This is a more generic approach, and much more
Marcus> useful than just to be able to mount one filesystem
Marcus> several times. It's also not implemented yet :)
Marcus> I think it might be quite easy to get the linux feature
Marcus> you describe, though. You just need to make a filesystem
Marcus> server advertise itself on a different node than its root
Marcus> node, too. Look at how the tunnel interface is set up in
Marcus> pfinet. It sets itself as the translator for
Marcus> /dev/tunX. From this moment, pfinet serves requests at
Marcus> /dev/tunX, /servers/socket/2 and all sockets to it. Now,
Marcus> pfinet does different things on each of these, but it
Marcus> would be even easier to do exactly the same thing on two
Marcus> translated nodes.
Ok. Good.
Marcus> If you'd really want this feature in a filesystem, you'd
Marcus> add another RPC which would tell the filesystem server to
Marcus> set itself as the translator on a certain node. (Or just
Marcus> pass the port directly). But I don't think it is too
Marcus> useful a feature. What's the difference between mounting
Marcus> several times and just setting symlinks? [1] [2]
symlinks, AFAIK, don't work in a chroot environment.
So if you want to access /home within a chroot environment, you are
out of luck.
(then again, this wont be a real issue until we have a stable
distribution).
Marcus> [1] In Linux, you don't get "sub mounts", in fact, there
Marcus> is nothing like a submount in linux. In the Hurd, you
Marcus> would always get the "submounts". To not get them, you'd
Marcus> need to take special precautions, and it would be quite
Marcus> impossible to do this cleanly, because even symlinks might
Marcus> just be implemented as translated nodes (see "showtrans
Marcus> /usr" for a faked example).
I am not familiarly with sub mounts (at least the terminology), what
do they allow you to do?
Marcus> [2] A symlink forwards a request to the other filesystem,
Marcus> while in the more direct approach, this middle man would
Marcus> be eliminated.
--
Brian May <bam@debian.org>
Reply to: