On Tue, Dec 23, 2008 at 11:14:16PM -0500, erik quanstrom wrote:
> > All of the same comments apply to /srv (though srv^2 is trying to solve
> > this).
> 
> not true.  import $server / /n/$server will give you access to srv on $server
> as /n/$server/srv.

Fair, but there's no reason to propose that an exportfs couldn't be the
target of a sendfd(), or that the underlying mechanism for sendfd() couldn't
be similarly exported (devcapsrv would work just fine, I think... maybe I
should just write it and post code?).

> what is "srv^2"?

EricVH's /srv replacement.  See
http://graverobbers.blogspot.com/2008/12/srv-next-generation-service-registry.html
 
> > 1) Sending files across namespaces so that I can spawn acme at rio startup
> > and plumb to it without having to recreate mounts in its namespace.
> 
> plumb "Local (bind|mount) args" will accomplish this.

Assuming that the resource can be named in the plumber's namespace?  This
works out less well for things like ramfs's that were told where to mount
(-m) and not to use /srv (-s).  Or is there something really sneaky going on
here that I don't know?

> > 2) Sending parts of namespaces around locally without needing to run an
> > exportfs in that namespace.  (i.e. open() a directory && sendfd() that to
> > another process who can mount() it.)  Among other things, this allows the
> > shell (and others) to easily offer the current working directory fd (rather
> > than path) to rio for tab completion.
> 
> you can't mount a random directory.

OK, fair, it's more of a bind().  The operation does not yet exist, but
should be quite easy to add.  Perhaps it isn't worth it.

> > 3) Some small thought about being able to implement srv^2 entirely in
> > userland, and what the primitives would look like.  sendfd() or the above
> > outlined devcapsrv seems better than the current devsrv to me, but I confess
> > I might be mistaken.
> 
> what's the advantage of implementing srv entirely in userland?

EricVH made some rumblings off-list about srv^2 being a userland thing, as
it's a relatively complex proposal.  Further, being able to write it
entirely in userland also means that it is a virtualizable service, which
/srv is not.

> - erik