On Wed, Sep 12, 2018 at 03:18:26PM +0200, Michal Privoznik wrote:
On 09/12/2018 12:46 PM, Pavel Hrdina wrote:On Wed, Sep 12, 2018 at 10:57:32AM +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.Hi, definitely good idea to remove code duplication! We have similar issue with the virDomainSetBlkioParameters for QEMU and LXC drivers. The code to set cgroup values is the same. Since the common object is domain how about introducing virDomainSetupBlkioTune and virDomainSetupMemTune and move it into domain_conf.c, that way we don't have to extract domain specific data into src/util.I'd rather remove stuff from doman_conf.c than add something there. It's already the biggest file by far margin: libvirt.git $ find . -type f -iname \*.c -exec du -h {} \; | sort -h 416K ./src/qemu/qemu_domain.c 696K ./src/qemu/qemu_driver.c 956K ./src/conf/domain_conf.c And moving code from domain_conf is something we do from time to time. Just look at all those virnet* includes at the beginning of domain_conf.h. Another reason for moving the code out is that blkio tune is not domain specific. In the future, we might want to limit say iohelper and thus move it into its specific cgroup. I'm not that convinced about 2/4 to be honest. Memory specification is pretty much domain centric.
Both seem to follow cgroups to a point, so they're process-centric, not domain-centric. So if they're needed on lower (src/util) layers, separating them makes sense. (Not that domain_conf does not deserve to get both the parser and the formatter to be split out at this line count)
But it follows my first point - moving code out from domain_conf.c. And it de-duplicates the code.Another benefit is that it will not cause me merge conflicts because I'm rewriting cgroup code and adding support for cgroup v2.
Such downstream branches should not interfere with upstream libvirt development. IOW: it's your opportunity as a maintainer to offer to merge this patch on top of your changes if merging them now would cause you too much trouble. ;) Jano
I don't think that code movement should cause that big of a trouble. You'll get some context conflicts but that's always the case with 30+ unmerged patches. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
