Re: [libvirt] [PATCH 1 of 2] Add internal cgroup manipulation functions

DB> My thought on the overall design of this internal API is that it DB> is too low level & pushing too much work to the caller. eg, the DB> caller would have to lookup virCGroupPtr objects for each DB> controller it cares about, Well, that's not what I had in mind, actually. DB> and has to remember the tunables & their data types. Not pushing the actual value names up to the caller is a reasonable abstraction, I suppose. It seems like in the future QEMU may want to use one type of memory limit, where LXC wants another. I can see LXC domains having multiple memory limits (soft, hard, per process, per group, etc) where those might not be meaningful to QEMU domains. DB> While this kind of interface is applicable for a general purpose DB> API, libvirt's needs are not general purpose. While LXC driver is DB> the only current user, as more controllers are added I anticipate DB> that QEMU driver might use cgroups, eg for I/O controls and CPU DB> schedular controls Indeed. DB> As such I'd expect an API to be at a slightly higher level of DB> abstraction, strongly typed and a single cgroup object associated DB> with a domain object. DB> virDomainObjPtr dom = ...driver's internal domain object... DB> virCGroupPtr cg = virCGroupNew(dom); DB> # Set domain memory limit to 1 GB DB> virCGroupSetMemory(cg, 1024 * 1024 * 1024); DB> # Remove all device permissions DB> virCGroupDenyAllDevices(cg); DB> # Allow access to /dev/null device DB> virCGroupAllowDevice(cg, 3, 1) DB> Some of the existing APIs could be made static since they'd be DB> needed anyway, but some could be re-design to be tailored to DB> the semantics we want. Okay, I'll reswizzle it and re-post. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms(a)us.ibm.com