Re: [9fans] New wiki pages about 9p services and building grids

[mycroftiv@sphericalharmony.com]

Richard Miller <9fans@ham...> wrote:
> Date: Sat, 2 Mar 2013 15:32:27 +0000
> Thanks for producing this compendium of useful information.
> One question - there's a mention of "hubfs", which I wasn't familiar
> with until I tracked it down in your contrib area.  Perhaps you could
> provide a reference?

Thanks for the feedback on the wiki pages and the suggestion.  I
created and linked a new wiki page with extensive hubfs documentation
and usage examples.

http://www.plan9.bell-labs.com/wiki/plan9/hubfs/index.html

I wrote hubfs several years ago after noticing the absence of a
general purpose "screen" type utility in Plan 9.  aux/consolefs is
focused on a particular use case, serial consoles.  I feel that the
excellent Plan 9 design (no tty and 9p to handle local/remote clients
identically) helped me luckily stumble into a very nice simple fs
design that does both "screen" and general purpose network pipe
muxing.

On my current grid, my main cpu server hosts hubfs and every other
machine connects to it and shares services into it, and accesses other
machines through it.  I have persistent shells from several Plan 9
systems and two linux systems always available, and a separate hubfs
is used for things like irc sessions and mail reading sessions and
telnet connections to BBSes.  My profile does import -a of the /srv of
the main cpu so i can type "hub main lapsh" on any node and then be
connected to the subshell with p9p rc running on my linux laptop which
has a 9p connect to the hubfs server.

I think hubfs is a nice design for bringing shells of machines on the
network into the 9p file namespace.  I don't take any personal credit
for any nice things about it, I just tried to find the simplest way to
make a "screen" for Plan 9 and modifying a ramfs to have pipe-like
semantics and a queue of client responses seemed like the simplest way
to do it.  As it happened, the simplicity of doing it that way made it
more general purpose than a TTY-based screen and let me separate the
management of the shells from the basic idea of pipe buffering/muxing.

I'm less experienced as a developer than many so there are probably a
few naive things and eccentricities in hubfs, but it has been very
useful to me and in my use and testing it is stable and resource
efficient since all it does is just copy bytes into static buffers and
fill the 9p requests that come in.  To me, the fact that getting rid
of the TTY layer means that "screen/tmux" functions can be done in a
vastly simpler way - with new functionality as a free bonus - is a
nice demonstration of the benefits of clean design.

Sorry if this response was unnecessarily long, but thanks for your
interest in the wiki pages and the suggestion to write up and link
hubfs for clarity.

-Ben Kidwell
"mycroftiv"