On 10/11/21 14:38, Olaf Hering wrote:
Am Mon, 11 Oct 2021 13:25:20 -0600 schrieb Jim Fehlig <jfehlig@suse.com>:
I think it is wrong to use internal libvirt values for internal libxentoollog values. What is gained over the sparse mapping? Are values not covered actually useful in practice? Also, how are the values specified when using the xl tool? A quick peek at the code seems to imply using more 'v' options. E.g. 'xl -vvvv ...'.
Since libvirt has no control about what libxentoollog values the authors use, it should provide a simple way to request a specific loglevel. xl decided to use the number of v's for it.
How does one correlate a specific log level to the correct number of 'v'? :-) IMO the sparse mapping we currently have is more intuitive.
If such a setting is actually needed, then the proper place would be /etc/libvirt/libxl.conf. And IMO we should avoid creating a new name that could potentially confuse users. If 'xentoollog_level' is the common jargon in xen, we should stick with the same name.
If that is an acceptable approach I will try to prepare a patch.
I must admit I'm not fond of another log level knob. For many classes of bugs, users would then need to tweak libvirtd.conf and libxl.conf to collect appropriate debug info. That said, there is prior art. Going back to your snipped question
I guess no other used library provides similar internal logging, this requirement is unique to libxenlight.so.
Sorry for not looking closer earlier, but the qemu driver has a similar setting in qemu.conf for the gluster libgfapi log level https://gitlab.com/libvirt/libvirt/-/commit/a944bd925902d9ecce81e08900ad6a1a... Jim