[libvirt] [PATCH 06/10] qemu: Reorganize qemuBuildDomainLoaderCommandLine call

John Ferlan jferlan at redhat.com
Wed Feb 17 12:40:58 UTC 2016



On 02/17/2016 03:44 AM, Peter Krempa wrote:
> On Tue, Feb 16, 2016 at 19:44:16 -0500, John Ferlan wrote:
>> Reorganize the module to put the function after the -cpu processing
>> to form a logical order of processing for qemuBuildCommandLine working
>> top down in the module.
> 
> I'm not really a fan of this ...
> 
>>
>> Signed-off-by: John Ferlan <jferlan at redhat.com>
>> ---
>>  src/qemu/qemu_command.c | 141 ++++++++++++++++++++++++------------------------
>>  1 file changed, 71 insertions(+), 70 deletions(-)
>>
>> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
>> index 9dbc4a3..70da921 100644
>> --- a/src/qemu/qemu_command.c
>> +++ b/src/qemu/qemu_command.c
>> @@ -790,6 +790,77 @@ qemuBuildCpuCommandLine(virCommandPtr cmd,
>>  }
> 
> It doesn't remove a forward declaration of a static function, just
> shuffles code around.
> 
>> +/** Start Domain Loader (-bios, file=%s,if=pflash) arguments */
> 
> This is yet another new style to the src/qemu subtree.
> 

Markers mostly - easily removed

>> +static int
>> +qemuBuildDomainLoaderCommandLine(virCommandPtr cmd,
> 
> I don't think it's worth moving the code so that it just is in the
> correct order. Is there any other reason?
> 
> Peter
> 


For me it was a choice of haphazard and mostly random placement vs.
ordered placement. It really doesn't matter that much to me; however,
once I started it was just easier to move stuff. Although it really was
horrible in difference management - especially when 300+ line functions
were moved (and there's vary feelings on code that has 300+ line helper
functions). That difference mgmt only became clear after I'd gone
through a bunch of changes and started looking back at the pile. Of
course a second deterrent becomes backport nightmares...

The real goal was to change qemuBuildCommandLine to not have "much"
inline code. It's currently >1100 lines long. Instead everything would
be some sort of qemuBuildXXXCommandLine() type call. I think I can get
that down to 250-300 lines.

When adding new functions I was conflicted on placement, so that Type A
thing kicked in and I started moving functions. I can change to purely
create new helpers. It wasn't that difficult to move - although much
more difficult to review. Along the way I've found some things that
should be static (mostly all QEMU_CAPS_DEVICE related).

It's really not all that difficult for me to change course and just go
with the new qemuBuildXXXCommandLine functions.

John




More information about the libvir-list mailing list