Re: [Qemu-devel] [PATCH] qemu/units: Move out QCow2 specific definitions

[Kevin Wolf <kwolf@redhat.com>]

Am 02.11.2018 um 15:52 hat Eric Blake geschrieben:
> On 11/2/18 9:10 AM, Kevin Wolf wrote:
> > Am 02.11.2018 um 13:37 hat Philippe Mathieu-Daudé geschrieben:
> > > Hi Kevin,
> > > 
> > > On 2/11/18 12:07, Kevin Wolf wrote:
> > > > Am 02.11.2018 um 09:58 hat Philippe Mathieu-Daudé geschrieben:
> > > > > This definitions are QCow2 specific, there is no need to expose them
> > > > > in the global namespace.
> > > > > 
> > > > > This partially reverts commit 540b8492618eb.
> > > > > 
> > > > > Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> > > > 
> > > > If we don't want this globally, I think we also don't want it in qcow2.
> 
> Agreed. I didn't want it in the first place, arguing that if we want
> stringification of defaults, it would be better to have a runtime function
> do that, rather than adding a set of near-duplicate macro names.
> 
> > > 
> > > I only see this definitions used by block/qcow2.h (b6a95c6d1007).
> > > 
> > > Per 540b8492618eb description "This is needed when a size has to be
> > > stringified" but I can't find other code requiring these definitions in the
> > > codebase.
> > 
> > I guess the real question is: Is qcow2 the only place that needs
> > stringification of sizes?
> 
> Probably not. It seems like stringifying a default value is a common desire.
> 
> > 
> > The only value where this actually seems to be used in qcow2 is for
> > DEFAULT_CLUSTER_SIZE, as the default value for QemuOpts. Other drivers
> > still use plain numbers, but this is less readable.
> > 
> > Then there is VDI which uses (1 * MiB), but that is compiled out and if
> > you enable it, it breaks. So it needs the same fix.
> > 
> > Are block drivers the only places where we stringify a size? I imagine
> > some device models might use something like it, too?
> 
> Indeed, I would prefer a patch that makes it possible for QemuOpts to
> pretty-print a default value using a generic runtime stringifier, rather
> than keeping these S_ macros around.

The thing is just, QemuOpts is completetly string based. The default
value field is const char*. Either we get rid of QemuOpts and switch
everything to QAPI (nice thought, but a little unrealistic in the short
term), or we add ways to add non-string values to QemuOpts (would
require significant development on a piece of code we want to get rid of
in the long term), or you keep doing stringification at build time
(which I believe is the only reasonable choice at the moment).

Kevin