
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@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