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"
