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

[Eric W. Biederman]

Herbert Poetzl <herbert@xxxxxxxxxxxx> writes:

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

Actually I agree.  That should work for everything except sysctl.

The tricky bit is going to be sticky a pid on the namespace group.
But the patch should be quite simple.

>> So I am trying to turn an ugly design choice into feature :)
>
> hmm, no, you are trying to multipy an ugly design :)

Well only a bit :)

I'm still trying to turn the fact that weird things wound
up in /proc into a feature.


> /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

Yes. Something like that.  It will take a little thinking.
But something that doesn't go away when a process does.

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

Agreed.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/