* Li Zefan <lizf@xxxxxxxxxxxxxx> [2009-03-18 11:09:27]: > CC: Balbir Singh > > Paul Menage wrote: > > On Tue, Mar 17, 2009 at 7:39 PM, Li Zefan <lizf@xxxxxxxxxxxxxx> wrote: > >>> - always display one line for each subsystem; if a subsystem is > >>> multiply-bindable then the "hierarchy id" and "num cgroups" columns > >>> may be empty or have multiple (comma or slash-separated?) values > >>> > >> Then "hierarchy id" is no long a single number.. > > > > Correct. > > > >>> - for a multiply-bindable subsystem, have a header line to indicate > >>> that the subsystem exists, and then a separate line for each bound > >>> instance of the subsystem. > >>> > >> I think it's better to show every subsystems including debug_subsys in > >> /proc/cgroups, and show exactly n lines of debug_susys if we have n > >> hierarcies with debug_subsys binded, but no header line. > > > > But that gives a contradiction when n == 0 - we can't show exactly 0 > > lines for an unbound multi subsys, and still show every subsystem. > > > > I don't see what's wrong with this behavior: > > multi subsys sits in rootnode if it's unbound, and is removed from > rootnode if it's binded at least in one hierarchy. > > > Does libcgroup actually parse /proc/cgroup? If not, maybe we should > > Balbir may answer this. :) We do parse /proc/cgroups to see what controllers/subsystems we have and if they are enabled. > > > just break the format now and replace it with something more > > extensible for future changes. > > > > Even /proc/cgroup is ok, I don't think we can break this based on assumption > that on one is making use of /proc/cgroups. :( > If fields are not removed I don't see an issue. I would however recommend version of /proc/cgroups, like we do for /proc/slabinfo in the future. Versioning does not allow us to remove fields, but addition can be handled in that manner. -- Balbir _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers