qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: Anthony Liguori <aliguori@us.ibm.com>
Subject: Re: [Qemu-devel] [PATCH] Add new function qemu_register_machines
Date: Fri, 22 May 2009 12:59:04 +0100	[thread overview]
Message-ID: <200905221259.05433.paul@codesourcery.com> (raw)
In-Reply-To: <4A167996.6030200@mail.berlios.de>

> well, it's a matter of personal taste whether you prefer
> to have one or two interfaces for machine registration.

True. This is not a performance critical bit of code and has a well bounded 
number of occurrences so I'm inclined to go for simplicity/clarity over 
efficiency.  If we use arrays I recommend doing so consistently, even in the 
single machine case. Given your goal is to avoid repeated code I'd also use 
something along the lines of:
#define qemu_register_machines(x) qemu_do_register_machines(x, ARRAY_SIZE(x))

> The new function is an improvement if you want to reduce
> lines of code and binary code size.
>
> Removing unused entries like register_machines from
> header files is also an improvement. This part of
> my patch is fixed now in QEMU HEAD, thanks Anthony!
>
> And adding "static" to a machine declaration which is
> only used locally is also an improvement (hw/spitz.c).
>
> I assume that you agree that those last two points are
> an improvement.

Yes.

> So the patch improves two details and adds something
> where people disagree about its usefulness.
>
> What now? Will the patch be rejected because you
> don't see an improvement? Will you fix the missing
> "static" yourself? Do you want a new patch without
> qemu_register_machines? Or a new patch which uses
> qemu_register_machines for all files with more than
> one machine?

I'm never going to approve a patch until I'm happy with all of it. In general 
this is why it's a bad idea to mix cleanups and new features. In this case 
your new feature obsoletes some of your cleanups, so the case for separate 
patches is less clear.  However unless I'm feeling particularly bored or 
enthusiastic I'm unlikely to split up or rework the patch for you.

Paul

      reply	other threads:[~2009-05-22 11:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-21 18:26 [Qemu-devel] [PATCH] Add new function qemu_register_machines Stefan Weil
2009-05-21 19:03 ` Anthony Liguori
2009-05-21 19:28   ` Stefan Weil
2009-05-21 20:13     ` [Qemu-devel] " Jan Kiszka
2009-05-21 20:19       ` Stefan Weil
2009-05-21 20:27         ` Jan Kiszka
2009-05-21 20:30           ` Anthony Liguori
2009-05-21 22:33 ` [Qemu-devel] " Paul Brook
2009-05-22 10:08   ` Stefan Weil
2009-05-22 11:59     ` Paul Brook [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200905221259.05433.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=aliguori@us.ibm.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).