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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/23/23 22:06, Laine Stump wrote:
> 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@xxxxxxxxxx>
>>> ---
>>>   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.
> 

Yeah, that would be a problem, but also such conflicts would be trivial
to resolve.

Michal




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux