[lxc-devel] cgroup management daemon
Tejun Heo
tj at kernel.org
Tue Dec 3 13:54:03 UTC 2013
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 at hallyn.com> 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
More information about the lxc-devel
mailing list