[libvirt PATCH 08/13] ch_cgroup: methods for cgroup mgmt in ch driver

Michal Prívozník mprivozn at redhat.com
Mon Nov 22 12:48:59 UTC 2021


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




More information about the libvir-list mailing list