Re: Hurd translators on FUSE

[Sergiu Ivanov]

Hello,

On Fri, Sep 25, 2009 at 04:09:07PM +1000, William Leslie wrote:
> > I must confess that I don't have the knowledge to understand what
> > specifically you are referring to by the term ``HurdIO'', but it did
> > occur to me that Hurd translators are more general (that's why I wrote
> > ``*most* translators'' :-) ).
> 
> What the filesystem really *is* under the Hurd is a way to locate Mach
> ports. These might implement a directory interface, or a file
> interface, or both, or something completely unrelated. All of the
> translators that make up the Hurd today implement at least one of
> these interfaces, because it makes using the translators easier (and
> adheres to the unix philosophy that bytestreams are the universal
> interface). However, these ports could refer to anything, for example,
> they could represent capabilities to some system resource, references
> to objects provided by some process (such as application windows under
> X11), etc. They may have no sensible interpretation as a file or
> directory.

I think I can now understand what is ``HurdIO'' :-) Of course, I know
about the things you have enumerated, but I didn't know the collective
name :-)

I wonder whether it is not at all possible to represent everything as
a file.  I heard that this is somehow implemented in Plan 9, but I'm
not sure how generic such a system can be.

However, I'm not sure whether the general idea of stripping port
interfaces and leaving only files is not incompatible with the design
of the Hurd and thus impossible to be applied to it.
 
> >  However, I'm actually thinking of
> > something like a ``prototype version'' whose main purpose would be
> > introducing the concept of translators to a wider public and
> > cultivating interest in the environment where the concept originated
> > from -- the Hurd :-)
> 
> It still sounds like something worth trying to me, but be aware that
> the Hurd system is really "files on top of rpc" which (at least I
> consider) is much cleaner than trying to do the reverse. Say, a
> translator that provides both a file interface and some other
> interface: how do you distinguish both uses on top of FUSE? Maybe you
> don't bother to support both interfaces at once, or you emulate rpc in
> all cases, or you don't support non-file APIs. Anyway, maybe you will
> deal with this problem when you come to it.

In the snippet of the libfuse README Arne has posted in this thread
the author mentions that FUSE supports programs that export several
filesystems.  I can't really imagine how FUSE does that, but that
might be a way out.

Regards,
scolobb