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(a)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