Re: [libvirt PATCH 08/13] ch_cgroup: methods for cgroup mgmt in ch driver
On 11/16/21 00:05, Praveen K Paladugu wrote:
I started refactoring this commit to have shared methods between qemu
and ch drviers for cgroup management. While doing so, I realized, I
still need a mechanism to identify what the underlying driver is : ch/qemu.
An example of it is the prefix for the cgroup to be created. Ch driver
is configured to have a prefix of "ch", while qemu driver configures the
prefix of the cgroup name to "qemu".
What is the best way to detect the underlying driver from
src/hypervisor? One way I could think of it is to extend
virQEMUDriver/virtCHDriver struct to also have a driver name which will
be checked from these shared methods. Any other recommendations for this
check?
Hey, sorry for replying this late, but I was on PTO.
I don't think I understand why src/hypervisor/* would need to see the
difference, but I'll be honest - maybe I did not think it through. My
expectation was that qemu_cgroup.c APIs get virCGroup pointer (or obtain
it from priv->cgroup) which already points to the correct, per guest
CGroup (in other words, points to /sys/fs/cgroup/.../qemu/... or
/sys/fs/cgroup/.../ch/...). Isn't that what you are seeing?
If you still need to know which driver called function under
src/hypervisor/ you can pass it as an argument to the function. For
instance, if the function depends on the driver, then it could look like
this:
int func(const char *prefix, ...)
{
...
path = g_strdup_printf("/sys/fs/cgroup/%s/some/file", prefix):
...
}
and then QEMU driver would call the function as:
func("qemu");
and CH driver would call it as:
func("ch");
Michal