On 6/21/07, Neal H. Walfield <neal@walfield.org> wrote:
> 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.
The first step of my plan is to support a list of string path like "SERVERS_SOCKET_PFINET="path1:path2". And after that I may consider support the fd:x semantic, where x should be a fd that is already opened. So, we need not to start any program in the code for overriding, but just query a port from either a path or a fd.
> 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.
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).
So a port of /chroot is returned to the client? If the client can access /chroot/foo, I think it can also access /chroot, or you may mean that
foo has a different parent node in the client's name space, which I think can not be achieved by chroot.