Hey, On Wed, Feb 11, 2015 at 12:29:20AM -0600, Eric W. Biederman wrote: > In general namespaces are not necessary if your scope of names > already has hierarchy. Which means that new interfaces can almost > always be designed in such a way that you can support containers without > needing to add any special namespace support. Which typically results > in more flexible and useful APIs for everyone, with no real code cost. Sure, and cgroup ns support isn't doing anything weird there. Just bind mounting a subhierarchy is enough for the core features. The ns part is dealing with things which can't easily be tied to such hierarchical scoping like path reported under through proc and even handling that can be achieved by, for example, marking delegation points in cgroup proper and forcing tasks beyond that point to consider that as its origin when determining the path to report. However, note that something like that is inherently similar to what's being provided by other namespaces. It is true that it can be implemented outside namespace facility proper but that doesn't automatically make that the right choice and it's more likely to be worse - we'd be introducing a different way to perform about the same thing. So, the argument that adding namespace interface except for backward compatibility doesn't seem to hold water. Like it or not, namespace is serving as a platform for certain type of features and we'd be foolish to not to consider putting a related feature together there and I fail to see a valid technical argument as of yet. > Further in the cgroup namespace patchset I looked at a while ago, the > only reason for having a cgroup namespace was to provide a measure of > backwards compatibility with existing userspace. I expect removing the > /proc/<pid>/cgroup file and replacing it with something in cgroupfs > itself would serve just as well if backwards compatibility is not the > objective. Or possibly replacincg /proc/<pid>/cgroup into a magic > symlink onto somewhere in the unified cgroupfs itself. No matter what we do, we'd still need to mark the delegation point somehow; otherwise, there's no way to produce a scoped identifier. This isn't really about backward compatibility but rather the feature to scope a subhierarcy properly. > I just don't see any point in doing weird silly namespace things to keep > existing userspace working when the existing userspace won't work. If it's too different from existing namespaces, sure, doing something is definitely an option but is it? > As such if a namespace doesn't implement compatibility with the existing > userspace it gets my nack. Hmmm.... I don't think making the proposed NS support to work across all hierarchies including the traditional multiple ones would be too difficult. That should work then, right? Thanks. -- tejun _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
