From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36300) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b7l10-0002v4-VT for qemu-devel@nongnu.org; Tue, 31 May 2016 10:51:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b7l0w-0002rO-Mh for qemu-devel@nongnu.org; Tue, 31 May 2016 10:51:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53819) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b7l0w-0002rG-EV for qemu-devel@nongnu.org; Tue, 31 May 2016 10:51:26 -0400 Date: Tue, 31 May 2016 11:51:24 -0300 From: Eduardo Habkost Message-ID: <20160531145124.GA7661@thinpad.lan.raisama.net> References: <20160509192515.GU4457@thinpad.lan.raisama.net> <877ff2fhjf.fsf@dusky.pond.sub.org> <20160510115705.GX4457@thinpad.lan.raisama.net> <87bn4djcgq.fsf@dusky.pond.sub.org> <20160511193550.GD24153@thinpad.lan.raisama.net> <87k2iz7m7i.fsf@dusky.pond.sub.org> <20160527201955.GK23701@thinpad.lan.raisama.net> <87mvn7evpp.fsf@dusky.pond.sub.org> <20160531120139.GO23701@thinpad.lan.raisama.net> <87shwycqcd.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87shwycqcd.fsf@dusky.pond.sub.org> Subject: Re: [Qemu-devel] [libvirt] [PATCH 7/9] qmp: Add runnability information to query-cpu-definitions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Christian Borntraeger , libvir-list@redhat.com, qemu-devel@nongnu.org, David Hildenbrand , Cornelia Huck , Igor Mammedov , Jiri Denemark , Andreas =?iso-8859-1?Q?F=E4rber?= On Tue, May 31, 2016 at 03:24:50PM +0200, Markus Armbruster wrote: > Eduardo Habkost writes: > > > On Mon, May 30, 2016 at 11:33:38AM +0200, Markus Armbruster wrote: > [...] > >> The new members encode an answer to the question whether a certain CPU > >> usable with the current machine an accelerator, and if no, why. > >> The possible answers are: > >> > >> (1) Don't know. > >> (2) Yes. > >> (3) No, but we can't say why. > >> (4) No, and here's a list of reasons. > >> > >> The two "dunno" answers (1) and (3) exist so we don't have to boil the > >> CPU ocean now. > >> > >> Without them, the natural solution is a single member, where (4) is > >> encoded as nonempty list, and (2) could be encoded as empty list or > >> absent. > >> > >> Now let me try to fit in (1) and (3). > >> > >> The obvious way to do (1) is absent. So let's use empty list for (2). > >> > >> That leaves (3). I think the simplest solution that could possibly work > >> is to treat it as a special "dunno" reason: encode it just like (4), but > >> with a special "dunno" list element. I'd use the empty string. > >> > >> Could even be used if we need to distinguish > >> > >> (4a) No, and here's the *complete* list of reasons. > >> (4b) No, and here's a possibly incomplete list of reasons. > >> > >> For (4b), include the "dunno" element with the others. > >> > >> Unlike the proposed solution, this one doesn't leave interface crud > >> behind if we succeed in getting rid of (1) and (3): > >> > >> * When (1) goes away, the single member becomes mandatory. > >> > >> * When (3) goes away, the special "dunno" list element no longer occurs. > > > > I like your suggestion. > > > > I suggest "type" as the "dunno" element. It would keep the > > existing "QOM property name" semantics, and it would just mean > > "sorry, the only advice we can currently give you is to choose a > > different CPU type". It even matches the previous documentation I > > sent describing the meaning of read-only property names. > > > > Rewriting the docs again: > > > > # Virtual CPU definition. > > # > > # @name: the name of the CPU definition > > -# @runnable: #optional Whether the CPU model us usable with the > > -# current machine and accelerator. Omitted if we don't > > -# know the answer. (since 2.7) > > -# @unavailable-features: #optional List of attributes that prevent > > +# @unavailable-features: #optional List of properties that prevent > > # the CPU model from running in the current > > -# host. Present only if @runnable is false. > > -# (since 2.7) > > +# host. (since 2.7) > > # > > # @unavailable-features is a list of QOM property names that > > # represent CPU model attributes that prevent the CPU from running. > > -# If the QOM property is read-only, that means the CPU model can > > -# never run in the current host. If the property is read-write, it > > +# If the QOM property is read-only, that means there's no known > > +# way to make the CPU model run in the current host. > > +# If the property is read-write, it > > # means that it MAY be possible to run the CPU model in the current > > # host if that property is changed. Management software can use it > > # as hints to suggest or choose an alternative for the user, or > > # just to generate meaningful error messages explaining why the CPU > > # model can't be used. > > Should we spell out the special case "type"? It is not exactly a special case (it is a read-only property like any other), but it's worth mentioning. I will change it to: # If the QOM property is read-only, that means there's no known # way to make the CPU model run in the current host. If # absolutely no extra information will be returned to explain why # the CPU model is not runnable, implementations may simply # return "type" as the property name. > > > +# If @unavailable-features is an empty list, the CPU model is > > +# runnable using the current host and machine-type. > > +# If @unavailable-features is not present, runnability > > +# information for the CPU model is not available. > > # > > # Since: 1.2.0 > > ## > > I'm happy with this interface. Thanks! Thanks! -- Eduardo