On Wed, Sep 06, 2023 at 12:14:54PM +0200, Philippe Mathieu-Daudé wrote:
> On 6/9/23 11:00, Daniel P. Berrangé wrote:
> > On Wed, Sep 06, 2023 at 06:42:16AM +0200, Philippe Mathieu-Daudé wrote:
> > > On 5/9/23 18:23, Peter Xu wrote:
> > > > Drop the enum in qapi because it is never used in QMP APIs. Instead
> > > > making
> > > > it an internal definition for QEMU so that we can decouple it from QAPI,
> > > > and also we can deduplicate the QAPI documentations.
> > > >
> > > > Reviewed-by: Daniel P. Berrangé <berra...@redhat.com>
> > > > Signed-off-by: Peter Xu <pet...@redhat.com>
> > > > ---
> > > > qapi/migration.json | 179
> > > > ---------------------------------
> > > > migration/options.h | 47 +++++++++
> > > > migration/migration-hmp-cmds.c | 3 +-
> > > > migration/options.c | 51 ++++++++++
> > > > 4 files changed, 100 insertions(+), 180 deletions(-)
> > >
> > >
> > > > diff --git a/migration/options.h b/migration/options.h
> > > > index 124a5d450f..4591545c62 100644
> > > > --- a/migration/options.h
> > > > +++ b/migration/options.h
> > > > @@ -66,6 +66,53 @@ bool migrate_cap_set(int cap, bool value, Error
> > > > **errp);
> > > > /* parameters */
> > > > +typedef enum {
> > > > + MIGRATION_PARAMETER_ANNOUNCE_INITIAL,
> > > > + MIGRATION_PARAMETER_ANNOUNCE_MAX,
> > > > + MIGRATION_PARAMETER_ANNOUNCE_ROUNDS,
> > > > + MIGRATION_PARAMETER_ANNOUNCE_STEP,
> > > > + MIGRATION_PARAMETER_COMPRESS_LEVEL,
> > > > + MIGRATION_PARAMETER_COMPRESS_THREADS,
> > > > + MIGRATION_PARAMETER_DECOMPRESS_THREADS,
> > > > + MIGRATION_PARAMETER_COMPRESS_WAIT_THREAD,
> > > > + MIGRATION_PARAMETER_THROTTLE_TRIGGER_THRESHOLD,
> > > > + MIGRATION_PARAMETER_CPU_THROTTLE_INITIAL,
> > > > + MIGRATION_PARAMETER_CPU_THROTTLE_INCREMENT,
> > > > + MIGRATION_PARAMETER_CPU_THROTTLE_TAILSLOW,
> > > > + MIGRATION_PARAMETER_TLS_CREDS,
> > > > + MIGRATION_PARAMETER_TLS_HOSTNAME,
> > > > + MIGRATION_PARAMETER_TLS_AUTHZ,
> > > > + MIGRATION_PARAMETER_MAX_BANDWIDTH,
> > > > + MIGRATION_PARAMETER_DOWNTIME_LIMIT,
> > > > + MIGRATION_PARAMETER_X_CHECKPOINT_DELAY,
> > > > + MIGRATION_PARAMETER_BLOCK_INCREMENTAL,
> > > > + MIGRATION_PARAMETER_MULTIFD_CHANNELS,
> > > > + MIGRATION_PARAMETER_XBZRLE_CACHE_SIZE,
> > > > + MIGRATION_PARAMETER_MAX_POSTCOPY_BANDWIDTH,
> > > > + MIGRATION_PARAMETER_MAX_CPU_THROTTLE,
> > > > + MIGRATION_PARAMETER_MULTIFD_COMPRESSION,
> > > > + MIGRATION_PARAMETER_MULTIFD_ZLIB_LEVEL,
> > > > + MIGRATION_PARAMETER_MULTIFD_ZSTD_LEVEL,
> > > > + MIGRATION_PARAMETER_BLOCK_BITMAP_MAPPING,
> > > > + MIGRATION_PARAMETER_X_VCPU_DIRTY_LIMIT_PERIOD,
> > > > + MIGRATION_PARAMETER_VCPU_DIRTY_LIMIT,
> > > > + MIGRATION_PARAMETER__MAX,
> > >
> > > MIGRATION_PARAMETER__MAX is not part of the enum, so:
> > >
> > > #define MIGRATION_PARAMETER__MAX \
> > > (MIGRATION_PARAMETER_VCPU_DIRTY_LIMIT + 1)
> >
> > IMHO the way it currently is written is better, because the
> > __MAX value is guaranteed to always have the right max value
> > without needing to be manually changed when new params are
> > added. Note this matches the code style used by the QAPI
> > enum generator too.
>
> This concern comes from a previous discussion with Richard (which I
> can't find now in the archives) where he explained to me __MAX is not
> part of the enum set, thus reduces the coverage of compiler sanitizers
> / optimizers, and could introduce subtle bugs.
>
> This motivated this series:
> https://lore.kernel.org/qemu-devel/20230315112811.22355-4-phi...@linaro.org/
> which should have changed that generated QAPI enum.
>
> (I didn't respin that series because I couldn't find an easy way to
> handle conditionals, see
> https://lore.kernel.org/qemu-devel/87sfdyaq0m....@pond.sub.org/)
Oh, I completely forgot about that series.
So the original problem is that with '-Wswitch' present, if the
switched variable is an enum type, the compiler complains if you
don't list all possible enum values, or have a default: clause.
Thus the existance of __MAX forces use to add case ...__MAX, or
have a default, and you wanted to eliminate that requirement.
Or the surface that sounds reasonable, but I actually think that
is the conceptually wrong approach from a robustness POV.
C (and some other languages) are terrible wrt enum declared
constants vs actual stored values.
You can have a variable declared KeyValueKind and it can store
absolutely any integer value at all, whether intentionally,
or by a code mistake or by data corruption.
In your example you modified:
switch (key->key->type) {
case KEY_VALUE_KIND_NUMBER:
qcode = qemu_input_key_number_to_qcode(key->key->u.number.data);
name = QKeyCode_str(qcode);
trace_input_event_key_number(idx, key->key->u.number.data,
name, key->down);
break;
case KEY_VALUE_KIND_QCODE:
name = QKeyCode_str(key->key->u.qcode.data);
trace_input_event_key_qcode(idx, name, key->down);
break;
case KEY_VALUE_KIND__MAX:
/* keep gcc happy */
break;
}
to remove KEY_VALUE_KIND__MAX.
What we should actually do IMHO is to either change it to
default:
g_assert_not_reached();
Or get extra paranoid and -Wswitch-enum too and list both
together
case KEY_VALUE_KIND__MAX:
default:
g_assert_not_reached();
This forces us to validate every enum case, and also protect
against out of range values.
This is a little more verbose to code, but I can't say it
has been a maint problem in libvirt where we've followed
this approach with -Wswitch-enum and _MAX constants.
> Back to this patch, I don't object to having MIGRATION_PARAMETER__MAX
> in the enum, but I'd rather have the suggestion below considered.
I just prefer to see consistency in approach across the codebase, and
currently we use __MAX approach.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
