[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] qemu/units: Move out QCow2 specific definitions
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH] qemu/units: Move out QCow2 specific definitions |
Date: |
Fri, 2 Nov 2018 15:10:30 +0100 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
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é <address@hidden>
> >
> > If we don't want this globally, I think we also don't want it in qcow2.
>
> 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?
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?
I don't mind too much which solution we end up using, but I'd prefer it
to be universal.
Kevin