[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

    >> - 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.


    >> - 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

    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: