From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53591 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmRyA-0004Hn-0b for qemu-devel@nongnu.org; Mon, 07 Feb 2011 09:21:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PmRy8-0007cp-NX for qemu-devel@nongnu.org; Mon, 07 Feb 2011 09:21:33 -0500 Received: from mail-ww0-f53.google.com ([74.125.82.53]:43157) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PmRy8-0007cY-EQ for qemu-devel@nongnu.org; Mon, 07 Feb 2011 09:21:32 -0500 Received: by wwi18 with SMTP id 18so4534825wwi.10 for ; Mon, 07 Feb 2011 06:21:31 -0800 (PST) Message-ID: <4D4FFFE3.8000205@codemonkey.ws> Date: Mon, 07 Feb 2011 08:21:23 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 03/16] qdev-properties: add PROP_TYPE_ENUM References: <1296773152-23279-1-git-send-email-alevy@redhat.com> <1296773152-23279-4-git-send-email-alevy@redhat.com> <20110207104348.GA5754@playa.tlv.redhat.com> <4D4FF08D.2040505@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org On 02/07/2011 08:05 AM, Markus Armbruster wrote: > Anthony Liguori writes: > > >> On 02/07/2011 04:43 AM, Alon Levy wrote: >> >>> On Mon, Feb 07, 2011 at 09:53:44AM +0100, Markus Armbruster wrote: >>> > [...] > >>>> Okay, let's examine how your enumeration properties work. >>>> >>>> An enumeration property describes a uint32_t field of the state object. >>>> Differences to ordinary properties defined with DEFINE_PROP_UINT32: >>>> >>>> * info is qdev_prop_enum instead of qdev_prop_uint32. Differences >>>> between the two: >>>> >>>> - parse, print: symbolic names vs. numbers >>>> >>>> - name, print_options: only for -device DRIVER,\? (and name's use >>>> there isn't particularly helpful) >>>> >>>> >>> Why do you say that? this is being used by libvirt to get the names of the >>> supported backends for the ccid-card-emulated device. >>> >>> >> This is wrong. >> >> Libvirt should query this information through QMP. >> > "We should make this information readily available through QMP", you > want to say ;) > > >> This is my main >> concern with enums. If there isn't a useful introspection interface, >> libvirt is going to do dumb things like query help output. >> > Beggars can't be choosers. > I'm making steady progress. I just finished device_add/device_del on a plane. I expect to have QMP fully converted in a couple weeks. There is a lot more than I anticipated that is not available in QMP vs. the HMP so that's going to take a bit more time. >> This has been a nightmare historically and I'm not inclined to repeat it. >> > No argument, but we can hardly expect poor Alon to finish the QMP job > just to get his usb-ccid device in. > Hint: enum shouldn't block usb-ccid. An enum is equivalent to a string property to convert as far as the current command line interface so just use a string property with a well documented set of inputs, and let's do enums properly. That's what I was suggesting in my previous replies to this series. > What would making him drop enum properties from his series accomplish? > We (or maybe just I) have to take QMP more seriously. I don't want to further make device properties incompatible with QMP which is what an enum property would do. > We'd get the same device with an inferior -device interface, which we > then have to maintain compatibly. > We can retroactively make the command line interface take a symbolic value of an enum when it previously took a string with no compatibility problem. But a QMP enum interface may not operate in strings. If it sends integer constants instead of strings, then we'll create a compatibility issue. Regards, Anthony Liguori