Re: hurd does NOT need /hurd
On Mon, May 20, 2002 at 01:52:29AM +0100, Andrew Suffield wrote:
> > The Hurd servers in /hurd indeed usualy conform to the Hurd server interface
> ^^^^^^
> > as defined by /include/hurd/*.defs. This interface is _stable_. There is
> > no need to version the binary interface as it is not allowed to change.
> ^^^^^^^^^^^^^^^^^^^^^
>
> Make up your mind.
Uh. There is a difference between an interface and the implementation of
that interface. The first comment was about Hurd server binaries, which can
come from untrusted users who are allowed to implement whatever they want in
response to a remote procedure call. The second comment was about the
actual interface definition, of what we expect reasonable servers to
implement. That is stable, well defined, never changed, and will never
change (only grow by more interfaces).
> This sort of lack of foresight is what makes ABI transitions so
> painful. Didn't people learn ANYTHING when changing from libc5 to
> libc6?
<plonk>
The Hurd had stable and network transparent interfaces before the libc5 to
libc6 transition happened.
> > Linux modules are not even remotely comparable to Hurd servers. Linux
> > modules are comparable to other binary plugins that are dynamically loaded
> > and unloaded at run time by some programs that support plugins.
>
> Linux modules provide mappings between one type of device and
> another. Hurd "servers" do the same. The difference is one of
> implementation, not of purpose. Take the lp module as an example. If
> you feel there are still some differences, I invite you to describe
> exactly how a hurd implementation of the lp functionality would differ
> from the one used on linux.
What would be gained by you understanding the difference? I would want to
know this before starting the effort. I would expect you to read my talk on
hurd.gnu.org first, so maybe you can start with that?
> > > It's just that linux doesn't have a well-defined way of having translators run
> > > as normal users(most run as root, or something).
> >
> > Linux has no way to run arbitrary translators by untrusted users. It
> > completely lacks the security concepts required to make it feasible.
>
> You missed the user-space nfsd/cfs/sfs/autofs examples, then, I
> see. I'm sure the authors would be interested to know that what they
> are doing isn't possible.
You have to read more carefully. I said "Linux has no way to run arbitrary
translators by untrusted users." What of this statement do you think is not
true? Do you mean that nfsd/cfs/sfs/autofs let untrusted users run
arbitrary translators? I have checked all these filesystems, and they seem
to be rather specific Linux filesystem kernel modules installed by the superuser.
Thanks,
Marcus
--
`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
--
To UNSUBSCRIBE, email to debian-hurd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: