hubfs man page


hub,  hubfs,  hubshell  - persistent multiplexed i/o sessions, or 'screen without a



hub [ -b ] [ srvname ] [ hubgroup ]

hubshell attachstring

hubfs [ -Dasm ] srvname


Hub invokes hubfs(1) to create a 9fs filesystem of pipe-like Hubs  available  as  a

/srv  and starts an rc(1) shell with its file descriptors redirected to these hubs,
then uses hubshell(1) as a client for these connections. The overall usage model is
somewhat  similar to GNU screen but without the additional complexities of TTY man-

The base behavior of hub(1) srvname is bimodal,  and  will  function  as  either  a
client  or server depending on whether /srv/srvname exists. If no name is provided,
hub will create or attach to a /srv named /srv/hubfs  containing  a  persistent  rc
session. Thus, the simplest possible model of use is:


to start a backgrounded hubfs hosted persistent rc shell, and then


from any window with access to that /srv to connect to it. The -b flag to hub back-
grounds the initially created rc instead of attaching to it.

Hubfs can be used to provide general purpose pipes locally  or  across  a  network,

with  some  special  features.  Most  notably,  echoing freeze to the ctl file will
change the behavior of the hub files from pipe-like with blocking reads  to  simple
static  files  that can be viewed and edited with normal tools. Writing melt to ctl
will restore pipe-like behavior and resume the normal flow of data.

While connected via a hubshell input beginning with a %symbol will be  checked  for
matching  command  strings.  These commands are used to create new subshells within
the hubfs session and move between them. A distinctive feature is the  ability  for
remote  clients  to share a local shell with other clients of the hubfs. The %local
NAME command does this. The more traditional mode of starting  new  shells  on  the
remote  host  is  done  with  the  %remote  NAME command. Note that 'remote' is the
machine hosting the shell you are connected to currently.  %detach  terminates  the
hubshell and returns control to the user's original shell.


hub wrapper script:

start and connect to a new hubfs and post /srv/aug5

       hub aug5

connects a new client to the rc shell started by the previous command

       hub aug5

start and connects to new rc named rctwo within the aug5 hubfs

       hub aug5 rctwo

Making new shells and moving in hubshell:

-all commands begin with '%' as first character-

       %detach  #disconnect from attached shell

       %remote NAME #start shell on remote machine

       %local NAME #start shell on local machine shared to hubfs

       %attach NAME #move to an existing hubfs shell

       %err TIME, %in TIME, %out TIME #time in ms for delay loop

       %status #basic hubfs connection info

       %list #lc of connected hubfs hubs

Controlling hubfs via the ctl file:

-reading from ctl file returns status-

       echo freeze >/n/hubsrv/ctl #freeze Hubs as static files

       echo melt >/n/hubsrv/ctl #resume normal flow of data

       echo fear >/n/hubsrv/ctl #activate paranoid mode

       echo calm >/n/hubsrv/ctl #resume non-paranoid mode

       echo quit >/n/hubsrv/ctl #kill the fs




UNIX pipes, pipe(3) , srv(3) and aux/consolefs(4)


The  command  parser is primitive. There are no provided options for giving clients
different levels of privilege to control the session. Mental incapacity to  grapple
with  the  combinatoric  possibilities  of  higher-dimensional pipe topologies (see
below). Reinvention of the wheel in octagonal form. Parameters such as data  bucket
size are compiled-in.


"Doug  had  for years and years, and he talked to us continually about it, a notion
of interconnecting computers in grids, and arrays, very  complex,  and  there  were
always problems in his proposals. That what you would type would be linear and what
he wanted was three-dimensional, n-dimensional...I mean he wanted just  topological
connection  of  programs and to build programs with loops and and horrid things. He
had such grandiose ideas and we were saying, the complexity you're generating  just
can't  be fathomed. You don't sit down and you don't type these kind of connections
together. And he persisted with the grandiose ideas where you get  into  Kirchoff's
law  problems...what  happens if you have a feedback loop and every program doubles
the number of characters, it reads one and writes two? It's got to go  somewhere  -
synchronization  - there's just no way to implement his ideas and we kept trying to
pare him down and weed him down and get something useful and distill it.  What  was
needed,  was  real  ideas...and  there  were  constant discussions all through this
period, and it hit just one night, it just hit, and they went in instantly."

~Ken Thompson on UNIX pipes' origins

No comments:

Post a Comment