[libvirt] [libvirt PATCH v3 0/4] Share cgroup code that is duplicated between QEMU and LXC

[Michal Privoznik]

On 09/13/2018 02:33 PM, Pavel Hrdina wrote:
> On Thu, Sep 13, 2018 at 09:48:10AM +0200, Fabiano Fidêncio wrote:
>> virLXCCgroupSetupBlkioTune() and qemuSetupBlkioCgroup() and
>> virLXCCgroupSetupCpuTune() and qemuSetupCpuCgroup() are the most similar
>> functions between QEMU and LXC code.
>>
>> Let's move their common code to virCgroup.
>>
>> Mind that the first two patches are basically preparing the ground for
>> the changes introduced in the last two patches.
>>
>> I know that Pavel Hrdina suggested taking a different path[0] for this
>> series but I do believe Michal's and Jano's points are valid, thus I've
>> decided to just do the changes suggested by Michal (at least for now).
> 
> That's OK, but I'm still not convinced that vircgroup.c is the correct
> place.  These new functions convert some data structure into multiple
> cgroup API calls.
> 
> By that logic we could do the same for virTypedParams which would lead
> into adding several helpers that would covert data structures into
> virTypedParams and that feels wrong.
> 
> Another thing that I don't like is moving the blkio and mem tune code
> into src/util because in util we have helpers to work with OS tools
> or OS related data and some really generic tools that could be easily
> used outside of libvirt and virtualization related code (yes, there are
> some exception that should be most likely fixed).

Well, blkio and memtune code is process oriented code (just like
bandwidth code for instance). It is true we currently use it only in
domain code, but that shouldn't be reason to keep it under src/conf.
Just like we are not keeping bandwidth code there.

> 
> If we want to deduplicate qemu_cgroup.c and lxc_cgroup.c we should
> introduce src/conf/domain_cgroup.c where we would place all common
> domain related code that configure cgroups.

In my view, src/conf should contain only XML configuration related code
(i.e. XML parser/formatter). It's only our laziness that we dumped a lot
of unrelated code there.

Anyway, this conversation now looks like bikesheding to me. The code
deduplication is what matters and where the code is going to live
doesn't matter that much. Therefore, I will no longer object.

Michal