[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 03/12] vfio-user: define vfio-user-server object

From: Markus Armbruster
Subject: Re: [PATCH v3 03/12] vfio-user: define vfio-user-server object
Date: Fri, 05 Nov 2021 11:08:29 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Kevin Wolf <kwolf@redhat.com> writes:

> Am 04.11.2021 um 13:13 hat Markus Armbruster geschrieben:
>> The old syntax almost always has its quirks.  Ideally, we'd somehow get
>> from quirky old to boring new in an orderly manner.  Sadly, we still
>> don't have good solutions for that.  To make progress, we commonly
>> combine JSON new with quirky old.
>> qemu-system-FOO -object works that way.  object_option_parse() parses
>> either JSON or QemuOpts.  It wraps the former in a QObject visitor, and
>> the latter in an opts visitor.
>> QemuOpts is flat by design[*], so the opts visitor parses flat QemuOpts
>> from a (possibly non-flat) QAPI type.  How exactly it flattens, and how
>> it handles clashes I don't remember.
>> Sadly, this means that we get quirky old even for new object types.
> For -object in the system emulator (the tools all use the keyval
> visitor, so there it would work as expected), the only reason that we
> need to keep the quirky old code path around is the list handling in
> memory-backend.host-nodes.
> The main difficulty there is that the old QemuOpts based code path
> allows specifying the option twice and both of them would effectively be
> combined. Do we have any idea how to replicate this in a keyval parser
> based world?

I can see just two clean solutions, but both involve upending a lot of

We can fuse keyval parser and visitor to get a schema-directed parser.

We can change the abstract keyval syntax to permit repeated keys.  This
means replacing QDict in in the abstract syntax tree, with fallout in
the visitor.

Even if we find a practical solution, I don't like the combination of
"you may give the same parameter multiple times, and the last one wins"
and "for a list-valued parameter, the values of repeated parameters are
collected into a list".  Each makes sense on its own.  The combination
not so much.  Inheriting "last one wins" from QemuOpts may have been a

The keyval way of doing lists (inherited from the block layer's usage of
dotted keys?  I don't remember) requires the user to count, which isn't
exactly nice, either.

> If not, do we want to use the remaining time until 6.2 to deprecate
> this? The nasty part is that the only syntax that works both now and in
> the future is JSON. We can't easily accept the new keyval syntax while
> still using the QemuOpts based code.

What exactly do you propose to deprecate?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]