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

Re: [libvirt] [PATCH 04/11] qemu_security: Kill code duplication



On 02/09/2017 10:52 AM, Peter Krempa wrote:
> On Thu, Feb 09, 2017 at 09:52:03 +0100, Michal Privoznik wrote:
>> On 02/08/2017 01:43 PM, Peter Krempa wrote:
>>> On Wed, Feb 08, 2017 at 13:37:48 +0100, Michal Privoznik wrote:
>>>> On 02/08/2017 01:23 PM, Peter Krempa wrote:
>>>>> On Wed, Feb 08, 2017 at 11:37:07 +0100, Michal Privoznik wrote:
>>>>>> Nearly all of these functions look the same. Except for a
>>>>>> different virSecurityManager API call. There is no need to copy
>>>>>> paste the code when we can use macros to generate it.
>>>>>>
>>>>>> Signed-off-by: Michal Privoznik <mprivozn redhat com>
>>>>>> ---
>>>>>>  src/qemu/qemu_security.c | 179 ++++++++++++-----------------------------------
>>>>>>  1 file changed, 44 insertions(+), 135 deletions(-)
>>>>>
>>>>> NACK, please don't partialy define function with macros.
>>>>>
>>>>
>>>> Why not? What is the downside?
>>>
>>> You'll never be able to navigate to the body of the function or ever
>>> find it try 'vim -t qemuSecurityRestoreHostdevLabel' or navigate to
>>> that after that patch.
>>>
>>> The downside of the code being totally unreadable is way worse than a
>>> few copied lines.
>>>
>>> (YU|NA)CK
>>>
>>
>> VIR_ONCE_GLOBAL_INIT
> 
> I've hit these a few times. In this case it irritates me that I can't
> see the ...Initialize function.
> 
>> KVM_FEATURE_DEF
> 
> This does not create functions.

Doesn't matter. From 'vim -t' POV it's the same thing. Even from
debugging POV it's the same thing (in gdb you'll see
IR_CPU_x86_KVM_CLOCKSOURCE_cpuid array but you will not find it in
sources). I don't see any difference, sorry.

Since we want to have variable names generated by macros, and there is
no difference to functions, I don't see the problem here.

Michal


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