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, olafbuddenha...@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-
