Hello, Tim. On Mon, Nov 25, 2013 at 08:58:09PM -0800, Tim Hockin wrote: > Thanks for this! I think it helps a lot to discuss now, rather than > over nearly-done code. > > On Mon, Nov 25, 2013 at 2:43 PM, Serge E. Hallyn <serge@xxxxxxxxxx> wrote: > > Additionally, Tejun has specified that we do not want users to be > > too closely tied to the cgroupfs implementation. Therefore > > commands will be just a hair more general than specifying cgroupfs > > filenames and values. I may go so far as to avoid specifying > > specific controllers, as AFAIK there should be no redundancy in > > features. On the other hand, I don't want to get too general. > > So I'm basing the API loosely on the lmctfy command line API. > > I'm torn here. While I agree in principle with Tejun, I am concerned > that this agent will always lag new kernel features or that the thin > abstraction you want to provide here does not easily accommodate some > of the more ... oddball features of one cgroup interface or another. Yeah, that's the trade-off but cgroupfs is a kernel API. It shouldn't change or grow rapidly once things settle down. As long as there's not too crazy way to step-aside when such rare case arises, I think pros outweight cons. > This agent is the very bottom of the stack, and should probably not do > much by way of abstraction. I think I'd rather let something like > lmctfy provide the abstraction more holistically, and relegate this > agent to very simple plumbing and policy. It could be as simple as > providing read/write/etc ops to specific control files. It needs to > handle event_fd, too, I guess. This has the nice side-effect of > always being "current" on kernel features :) The level of abstraction is definitely something debatable. Please note that the existing event_fd based mechanism won't grow any new users (BTW, event_control is one of the dos vectors if you give write access to it) and all new notifications will be using inotify. Thanks. -- tejun -- 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
