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 [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
