Re: passive translators

[Wei Shen]

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.

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

 

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.

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.

 

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.

 

Wei