From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Wed, 24 Dec 2008 02:36:06 -0500
From: Nathaniel W Filardo <nwf@cs.jhu.edu>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-ID: <20081224073606.GS9593@masters10.cs.jhu.edu>
References: <20081224030043.GR9593@masters10.cs.jhu.edu>
	<2967b3806a673eba836c697c763ab61b@quanstro.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="+hLoyg/derPMoKTw"
Content-Disposition: inline
In-Reply-To: <2967b3806a673eba836c697c763ab61b@quanstro.net>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [9fans] sendfd() on native Plan 9?
Topicbox-Message-UUID: 6ec7f86c-ead4-11e9-9d60-3106f5b1d025


--+hLoyg/derPMoKTw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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).
>=20
> not true.  import $server / /n/$server will give you access to srv on $se=
rver
> 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-regist=
ry.html
=20
> > 1) Sending files across namespaces so that I can spawn acme at rio star=
tup
> > and plumb to it without having to recreate mounts in its namespace.
>=20
> 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 t=
he
> > shell (and others) to easily offer the current working directory fd (ra=
ther
> > than path) to rio for tab completion.
>=20
> 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 abo=
ve
> > outlined devcapsrv seems better than the current devsrv to me, but I co=
nfess
> > I might be mistaken.
>=20
> 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

--+hLoyg/derPMoKTw
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklR5mYACgkQTeQabvr9Tc880ACeLWkYkVwm5MgV/+b1RsoqKVTp
3ZkAn03snK/+tqQDzTZ15+VIPRQMwZ9P
=DGeG
-----END PGP SIGNATURE-----

--+hLoyg/derPMoKTw--