Re: Hurd translators on FUSE

[William Leslie]

2009/9/25 Sergiu Ivanov <address@hidden>:
> Hello,
>
> On Fri, Sep 25, 2009 at 02:08:24PM +1000, William Leslie wrote:
>> 2009/9/25 Sergiu Ivanov <address@hidden>:
>> > I wonder whether it is reasonable to try FUSE to implement
>> > translators.  I've never been much into FUSE, but the Wikipedia
>> > article says that ``FUSE is particularly useful for writing virtual
>> > file systems'', which, AIUI, is precisely the matter of interest for
>> > most translators.  (At least FUSE filesystems like GmailFS,
>> > WikipediaFS, archivemount sound a lot like actual translator names.)
>>
>> Afraid not. Hurd translators are far more general. With FUSE you
>> provide file or directory like APIs, with HurdIO you can provide any
>> API. The more common subset of hurdio (the file and directory APIs)
>> might be portable to fuse, however.
>
> 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.

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

William Leslie