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