From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <2967b3806a673eba836c697c763ab61b@quanstro.net>
To: 9fans@9fans.net
From: erik quanstrom <quanstro@quanstro.net>
Date: Tue, 23 Dec 2008 23:14:16 -0500
In-Reply-To: <20081224030043.GR9593@masters10.cs.jhu.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] sendfd() on native Plan 9?
Topicbox-Message-UUID: 6ec27edc-ead4-11e9-9d60-3106f5b1d025

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

what is "srv^2"?

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

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

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

- erik