qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Options for 4.0


From: Markus Armbruster
Subject: Re: [Qemu-devel] Options for 4.0
Date: Mon, 01 Apr 2019 21:54:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Kevin Wolf <address@hidden> writes:

> Am 01.04.2019 um 15:11 hat Markus Armbruster geschrieben:
>> Kevin Wolf <address@hidden> writes:
>> > Option 4:
>> >
>> > Add a dummy option to BlockdevOptionsFile:
>> >
>> >     '*x-auto-read-only-is-dynamic': { 'type': 'null',
>> >                                       'if': 'defined(CONFIG_POSIX)' }
>> >
>> > Specifying it has no effect, so the ridiculous complexity of three bools
>> > to select from three options is avoided. Its presence in the schema
>> > indicates that file-posix implements dynamic auto-read-only.
>> >
>> > Basically this is features flags in the schema without having proper
>> > feature flags yet.
>> >
>> > Once we add real annotations (hopefully 4.1), this dummy field can be
>> > removed again.
>> 
>> Exact same patch as for option 3, with the parameter renamed and the
>> sanity check for non-sensical use dropped.  *Shrug*
>> 
>> Puts more pressure on me to deliver QAPI feature flags sooner rather
>> than later.  My QAPI pressure control valve has been shedding pressure
>> for a while, so "bring it on".  I'd advise against holding your breath,
>> though.
>
> Okay, let's stop beating around the bush.
>
> Nobody has told me so explicitly during this discussion, but implicitly
> I understand that everyone seems to think doing annotations in the
> schema is what we really want to have.
>
> Instead of continuing to argue which option to get around it is the
> least ugly one - how bad is the following attempt at just implementing
> what we really want?
>
> Only for structs for now, but that's all we need at the moment. Should
> be easy to extend during the 4.1 cycle (or whenever we need something
> else).
>
> Note that even if there are bugs in it, they are not user-visible and
> can just be fixed in 4.1. Currently, a diff between old and new
> query-qmp-schema output looks sane - just the added 'features' list
> where we want it.

[Patch snipped...]

Caveat emptor: at this time of day, I'm perfectly capable of missing the
obvious.  Assuming I don't: for once, something doesn't turn out six
times as hard as anticipated.

Missing:

* Test coverage: two negative tests for the two errors, positive
  coverage in qapi-schema-test.json

* Update to introspect.json (without this, qmp-cmd-test fails, and with
  qapi-schema-test.json updated, test /visitor/input/qapi-introspect
  will fail, too),

* Update a few tests/qapi-schema/*.err

* Update docs/devel/qapi-code-gen.txt

* A general idea how to document feature flags

* Depending on that, perhaps an update to the documentation generator
  scripts/qapi/doc.py

* A rough idea on where else feature flags need to go



reply via email to

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