Re: passive translators

[Neal H. Walfield]

At Thu, 21 Jun 2007 20:02:35 +0800,
Wei Shen wrote:
> 
> On 6/21/07, Neal H. Walfield <neal@walfield.org> wrote:
> >
> > At Thu, 21 Jun 2007 15:37:49 +0800,
> > > Could you please give some explanation on "PFINETSERVER=fd:3 myprog
> > > 3</path/to/pfinet"? What does "myprog 3<" mean, the naming closure?
> >
> > From the bash manual:
> >
> > 3.6.1 Redirecting Input
> >
> > Redirection of input causes the file whose name results from the
> > expansion of word to be opened for reading on file descriptor n, or
> > the standard input (file descriptor 0) if n is not specified.
> 
> 
> Ok, I got it. I will consider to support the file descriptor reprentation,
> but will not implement complex semantics as redirection first.

Redirection is a shell feature.  If you support the file descriptor
representation, then you can use the shell's redirection feature to
set up the file descriptors in the child process.  There is nothing
that you have to add.

> > (1) Assume a chroot process invokes "settrans -cp /foo /hurd/firmlink /".
> > >
> > > (2) The fs server will associate node /*foo* (/chroot/foo) with
> > translator *
> > > firmlink*. Since the fs server knows the quest is from a chroot process,
> > > it can save a chroot attribute "/chroot" (it is a string representation
> > of
> > > the chroot path, but not a handle or other expressions of capability),
> > in
> > > addition to the translator command "/hurd/firmlink /".
> >
> > The translator does not necessarily know a symbolic representation for
> > the capability passed to file_reparent.
> 
> 
> I can not understand. Sorry for keeping bothering you :-), but I expect to
> make it clear.
> Representation for which capability do you mean? The file node, parent, or
> target?
> Two ports (*node*, *parent*) and a string path (*target*_*name*) are passed
> to *firmlink*, and port *parent* and *target* are passed to* file_reparent*.

The translator does not necessarily know the symbolic representation
for any of the capabilities and it can't invoke them to "ask nicely".

> I proposed two solutions in last mail. In solution a), the translator is
> started chrooted. So the file node, parent, and target are respectively:
> /foo, /, and / in its eyes; and /chroot/foo, /chroot, and /chroot in
> reality.

What is reality?  These are only symbolic names: you need to establish
a naming context, and this is the root of the problem.

> I am not sure if this translator can still serve non-chrooted processes.
> Even if it can not, I do not think this is a problem, so long as it can work
> in the chroot domain.

We discuss an example where this causes problem in the critique
(think: client with a different global name space looks up .. at the
translator's root).

> In solution b), the translator is started as usual, but it will find a
> chroot argument is passed to it, so it should initiatively check the target
> path argument, and add /chroot in front of / to be /chroot/. Since the
> translator acts in the normal way, I think it should not be unable to
> understand the symbolic representation.

I think this will only introduce confusion: the translator has to be
very careful when it exposes symbolic names.

Neal