Re: [RFC] [PATCH 0/7] Some basic vserver infrastructure

[Herbert Poetzl <herbert@13thfloor.at>]

On Fri, Mar 24, 2006 at 02:13:40PM -0700, Eric W. Biederman wrote:
> Herbert Poetzl <herbert@13thfloor.at> writes:
> 
> > hmm, isn't per process a little extreme ... I know
> > what you want to accomplish but won't this lead to
> > a per process procfs? 
> 
> Where all of the values vary per process possibly, that
> is they way /proc is supposed to be.
> 
> /proc/sys is the only case that I think really gets extreme. For
> things like /proc/sysvipc and /proc/net it really is a natural break,
> and /proc/mounts already shows that the technique works fine.

well, while /proc/mounts is a good example that it 'works'
it isn't a good example for proper design, as the entire
private namespaces lead to much obfuscation, and having
the mounts per process, where they actually should be per
namespace, and to hide the fact that there are different
namespaces does not help either ...

IMHO a much better design would be to have the namespace
'explicit' and link to that one, containig the mounts entry
btw, this is something which should still be possible
without breaking anything ...

> So I am trying to turn an ugly design choice into feature :)

hmm, no, you are trying to multipy an ugly design :)

> > and, if you want to do per
> > process procfs, what would be the gain?
> >
> > just my opinion ...
> 
> Under the covers the implementation is per namespace, but
> it isn't easy to export it that way from procfs.

why?

/proc/self -> YYY/
/proc/mounts -> self/mounts

(so far nothing new)

/proc/YYY/namespace -> ../namespace-XXX/
/proc/YYY/mounts -> namespace/mounts 

(or alternatively)

/proc/namespace -> namespace-XXX/
/proc/mounts -> namespace/mounts

> In any event this appears to be a way to implement these things while
> retaining backwards compatibility, with the current implementation,
> and it looks like it can be implemented fairly cleanly.

I don't see any differences regarding compatibility when
things like namespaces get explicit ...

best,
Herbert

> Eric