Hi Tejun, On Thu, Aug 15, 2013 at 05:09:37PM -0400, Tejun Heo wrote: > I think the configuration rules are too complex. Without being privy > to the implementation itself, the restrictions seem mostly arbitrary. > The thing with this sort of greedy restrictions is that it might seem > okay for a while after enough tweaking (the current state) but it gets > weird as soon as the circumstance changes a bit and all the tweakings > quickly become extra baggages to carry around. Agreed. > e.g. if a cgroup will be allowed to be moved to another position in > the hierarchy, the cgroup shouldn't change its configuration across > such migration, right? If so, we'd be allowing creating a cgroup > outside the hierarchy with any configuration moving it under another > while disallowing creating it under there and creating the same > configuration, which would be an outright buggy behavior. Hm, then I think I got the requirements wrong. On my understanding you cannot have a cgroup with more access than its parent. And the reason for that is at that time the idea of having a container able to control its own hierarchy was valid. The way it is right now, when moved, a cgroup would have its active rules re-checked for permission and it'd be made an attempt to apply local rules if the new parent allows it. > The thing is I really don't like specific config change triggering > different actions. It really should be "this chagned, recalculate all > rules in this sub-hierarchy" rather than "this may affect XXX and YYY > but not ZZZ so let's trigger this subpart". The latter is way more > tricky to fragile and difficult to follow and verify. In addition, to > support migration, it should be ready for any set of config changes in > a go anyway. IIRC it was to simplify the code. That can change of course. > That's what cgroup_sane_behavior() is for. It's essentially the next > revision of cgroup interface. Understood, I think after we get the internals sorted out (like going for allow all or allow the listed) first > The reason why I want to get rid of disallow w/ exceptions is that > it's difficult to stack properly and ends up with this hodgepodge of > restrictions which can serve a set of contorted requirements at the > cost of overall consitent design which can be evolved and maintained > in the long term. If the majority of use cases are whitelisting, I > think it'd be a better idea to just stick with whitelisting. OK, will work on that -- Aristeu -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
