Re: [9front] srv(3) clone and srvid

[ori@eigenstate.org]

Quoth Jacob Moody <moody@mail.posixcafe.org>:
> On 3/29/23 11:45, unobe@cpan.org wrote:
> > I'm trying to run ndb/dns in a separate namespace so that I can use it
> > to forward requests (in the namespace) to another DNS server.
> > Recently, ndb/dns was updated to use /srv instead of '#s', which is
> > necessary to keep it separate from the primary devsrv.  srv(3) states
> > I can clone /srv and access that in two ways, via /srv/id or directly
> > using srvspec:
> > 
> >           bind -c #s$srvspec /srv
> > 
> >           /srv/clone
> >           /srv/id/...
> >           /srv/service1
> >           /srv/service2
> > 
> > The functionality is explained near the end of the man page:
> >           Opening the clone file allocates a new service directory.
> >           Reading clone returns the id of the new directory.  This new
> >           service directory can then be accessed at /srv/id.  Directo-
> >           ries are recursive; each new service directory contains its
> >           own clone file and sub-directories.  Directories can be
> >           walked from the root such as #s/id1/id2/id3 which makes them
> >           globally addressable.  As a convention, /lib/namespace
> >           accepts the path to the service directory from the environ-
> >           ment variable $srvspec, making it possible to start a new
> >           namespace using a specific service directory as a starting
> >           point.
> > 
> > If I do:
> > 	cpu% cat /srv/clone
> > 	15cpu%
> > 
> > I get a new id.  I expected to be able to go to the clone using
> > /srv/15, but that is not available:
> > 	cpu% lc /srv/15
> > 	ls: /srv/15: '/srv/15' file does not exist
> > 
> > I can, however, specify the srvspec to (supposedly) bind to a new
> > service directtory:
> > 	cpu% srvspec=`{cat /srv/clone} bind -c '#s'^$srvspec /srv
> > 	cpu%
> > 
> > Yet I would have expected this cloned service directory to be
> > disassociated from its parents so that manipulating it would not
> > affect the parent.  Right now, that is not the case.  If I rm
> > /srv/dns', after cloning the service directory, it is reflected across
> > all namespaces.  Is this a feature that hasn't been implemented?  Am I
> > misunderstanding how it's meant to work?
> > 
> 
> Yes, clone works like how it does in /net, the board is only open for as long
> as you have the fd open. So you cat'd it which opened it, read the new id, then closed
> it deallocating the child srv. You need to keep the fd open for the length of time you
> use the child srv, Or if you wish to 'pin' the child srv you can stash the clone fd itself
> as a file in the child srv. This will keep the child srv around until you remove the pinned
> clone fd.
> 

for an example of how it's used on shithub:
	
	<[3]/srv/clone{
		d=`{<[0=3]read}
		bind /srv/$d /srv
		# ugly, but we don't want to leak the clone fd into
		# procs that may stick around, so write over fd3 again
		<[3=0]{
			rfork n
			bind /usr/web /mnt/static
			execfs -m /usr/web /sys/lib/tcp80/gitrules
			bind /mnt/static /usr/web/static
			rfork n
			cd /
			exec /bin/tcp80
		}
	}