[libvirt PATCH v3 8/8] qemu: turn two multiline log messages into single line

Laine Stump laine at redhat.com
Wed Aug 23 20:06:39 UTC 2023


On 8/23/23 3:52 AM, Michal Prívozník wrote:
> On 8/21/23 21:32, Laine Stump wrote:
>> Normally I wouldn't bother with a change like this, but I was touching
>> the function anyway, and wanted to leave it looking nice and tidy.
>>
>> Signed-off-by: Laine Stump <laine at redhat.com>
>> ---
>>   src/qemu/qemu_driver.c | 6 ++----
>>   1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
>> index f676744e9e..a60cbf0ed4 100644
>> --- a/src/qemu/qemu_driver.c
>> +++ b/src/qemu/qemu_driver.c
>> @@ -11411,8 +11411,7 @@ qemuNodeDeviceDetachFlags(virNodeDevicePtr dev,
>>        */
>>       if (STREQ_NULLABLE(driverName, "kvm")) {
>>           virReportError(VIR_ERR_ARGUMENT_UNSUPPORTED, "%s",
>> -                       _("'legacy KVM' device assignment is no longer "
>> -                         "supported on this system"));
>> +                       _("'legacy KVM' device assignment is no longer supported on this system"));
>>           return -1;
>>       }
>>   
>> @@ -11423,8 +11422,7 @@ qemuNodeDeviceDetachFlags(virNodeDevicePtr dev,
>>   
>>       if (!qemuHostdevHostSupportsPassthroughVFIO()) {
>>           virReportError(VIR_ERR_ARGUMENT_UNSUPPORTED, "%s",
>> -                       _("VFIO device assignment is currently not "
>> -                         "supported on this system"));
>> +                       _("VFIO device assignment is currently not supported on this system"));
>>            return -1;
>>       }
>>   
> 
> This got me thinking, whether we should do one huge commit which would
> fix ALL the error messages in all files and just be done with it for
> good. Again, future work, you patch is good as is.

Yep, I had that thought too. I do worry that single giant mega-patches 
like that can create merge conflicts later though (since cherry-picking 
the mega-patch to resolve one conflict in context can create several 
other conflicts), but as you say that can be done (including the 
discussion of its relative merits) at another time.



More information about the libvir-list mailing list