Re: Many questions about translators

[olafBuddenhagen]

Hi,

On Wed, Apr 21, 2010 at 12:08:25PM +0200, Carl Fredrik Hammar wrote:
> On Tue, Apr 20, 2010 at 08:49:16AM +0200, olafBuddenhagen@gmx.net wrote:

> > > > I'm still not convinced that this is a good idea in general. Private
> > > > namespaces always make things somewhat intransparent IMHO.
> > > 
> > > I agree, unless perhaps it is obviously private, e.g. /proc/self.
> > 
> > Well, this is not really different from the magic lookups implemented so
> > far (TTY, FDs) -- so the obvious thing to do is just adding another
> > magic lookup type.
> > 
> > The difference with /proc/self is that the PID is kind of public; so it
> > *could* be handled server-side, if we really wished... But as long as
> > /proc/self is the only use case, it's probably not worthwhile.
> 
> Well, it might be possible to implement the other magic lookups
> which access to the client's process, which would simplify the
> lookup protocol and make it easier to extend (adding a server is
> easier than changing glibc and making sure all client uses the
> new library).

The problem with the other magic lookups is that they rely on data which
(AFAIK) is private to the process; so implementing it server-side seems
rather pointless... While there is an RPC for proc to ask a precesses
TTY, I don't think there is any method so far for asking the FDs. It
would require introducing a new RPC to ask for the FDs, only to pass
them back to the client -- I don't see how this would be an improvement
over the current approach.

Of course it *would* be possible to handle this in a nicer fashion,
using mandatory object migration... Perhaps that's what you meant? Not
sure whether we discussed that option before -- my memory on such things
really got very bad recently :-(

-antrik-