Re: [libvirt] [PATCH 06/10] qemu: Reorganize qemuBuildDomainLoaderCommandLine call
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(a)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