From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36397 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmS3t-0007FK-Bh for qemu-devel@nongnu.org; Mon, 07 Feb 2011 09:27:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PmS3r-0000UH-OX for qemu-devel@nongnu.org; Mon, 07 Feb 2011 09:27:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:27955) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PmS3r-0000U8-Dt for qemu-devel@nongnu.org; Mon, 07 Feb 2011 09:27:27 -0500 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p17ERQNn012500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 7 Feb 2011 09:27:26 -0500 Date: Mon, 7 Feb 2011 16:27:21 +0200 From: Alon Levy Subject: Re: [Qemu-devel] [PATCH 03/16] qdev-properties: add PROP_TYPE_ENUM Message-ID: <20110207142720.GI5754@playa.tlv.redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Mon, Feb 07, 2011 at 03:00:25PM +0100, Markus Armbruster wrote: > Alon Levy writes: > > > On Mon, Feb 07, 2011 at 09:53:44AM +0100, Markus Armbruster wrote: > >> I haven't been able to follow the evolution of this series, my apologies > >> if I'm missing things already discussed. > >> > >> Alon Levy writes: > >> > >> > Example usage: > >> > > >> > EnumTable foo_enum_table[] = { > >> > {"bar", 1}, > >> > {"buz", 2}, > >> > {NULL, 0}, > >> > }; > >> > > >> > DEFINE_PROP_ENUM("foo", State, foo, 1, foo_enum_table) > >> > > >> > When using qemu -device foodev,? it will appear as: > >> > foodev.foo=bar/buz > >> > > >> > Signed-off-by: Alon Levy > >> > --- > >> > hw/qdev-properties.c | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++ > >> > hw/qdev.h | 15 ++++++++++++ > >> > 2 files changed, 75 insertions(+), 0 deletions(-) > >> > > >> > diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c > >> > index a493087..3157721 100644 > >> > --- a/hw/qdev-properties.c > >> > +++ b/hw/qdev-properties.c > >> > @@ -63,6 +63,66 @@ PropertyInfo qdev_prop_bit = { > >> > .print = print_bit, > >> > }; > >> > > >> > +/* --- Enumeration --- */ > >> > +/* Example usage: > >> > +EnumTable foo_enum_table[] = { > >> > + {"bar", 1}, > >> > + {"buz", 2}, > >> > + {NULL, 0}, > >> > +}; > >> > +DEFINE_PROP_ENUM("foo", State, foo, 1, foo_enum_table), > >> > + */ > >> > +static int parse_enum(DeviceState *dev, Property *prop, const char *str) > >> > +{ > >> > + uint8_t *ptr = qdev_get_prop_ptr(dev, prop); > >> > >> uint8_t is inconsistent with print_enum() and DEFINE_PROP_ENUM(), which > >> both use uint32_t. > > > > Thanks, fixing. > > > >> > >> > + EnumTable *option = (EnumTable*)prop->data; > >> > >> Please don't cast from void * to pointer type (this isn't C++). > >> > > > > Will fix for all references. > > > >> Not thrilled about the "void *data", to be honest. Smells like > >> premature generality to me. > >> > > > > I did put it in there because I didn't think a "EnumTable *enum" variable > > would have been acceptable (added baggage just used by a single property type), > > and I didn't find any other place to add it. I guess I should just do a: > > > > typedef struct EnumProperty { > > Property base; > > EnumTable *table; > > } EnumProperty; > > > > But then because we define the properties in a Property[] array this won't work. > > Maybe turn that into a Property* array? > > Doubt the additional complexity just for keeping EnumTable out of > Property is worth it. > > > In summary I guess data is a terrible name, but it was least amount of change. Happy > > to take suggestions. > > Further down, we discuss the idea of supporting an EnumTable with > arbitrary integer type properties. Would you find an EnumTable member > of Property more palatable then? > I would. > >> > + > >> > + while (option->name != NULL) { > >> > + if (!strncmp(str, option->name, strlen(option->name))) { > >> > >> Why strncmp() and not straight strcmp()? > >> > > > > I guess no reason except "strncmp is more secure" but irrelevant here since > > option->name is from the source, I'll fix. > > > >> > + *ptr = option->value; > >> > + return 0; > >> > + } > >> > + option++; > >> > + } > >> > + return -EINVAL; > >> > +} > >> > + > >> > +static int print_enum(DeviceState *dev, Property *prop, char *dest, size_t len) > >> > +{ > >> > + uint32_t *p = qdev_get_prop_ptr(dev, prop); > >> > + EnumTable *option = (EnumTable*)prop->data; > >> > + while (option->name != NULL) { > >> > + if (*p == option->value) { > >> > + return snprintf(dest, len, "%s", option->name); > >> > + } > >> > + option++; > >> > + } > >> > + return 0; > >> > >> Bug: must dest[0] = 0 when returning 0. > >> > > > > will just return snprintf(dest, len, "", option->value) > > Print something useful is a good idea. I guess I'd print an unadorned > "%d". > Agreed. > >> > +} > >> > + > [...] > >> > + } > >> > > >> > #define DEFINE_PROP_UINT8(_n, _s, _f, _d) \ > >> > DEFINE_PROP_DEFAULT(_n, _s, _f, _d, qdev_prop_uint8, uint8_t) > >> > >> 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. > > Too terse, let me try again :) > > - name, print_options: differences not important here, because these > members are they are only for -device DRIVER,\? > > By the way, I don't find help output like > > e1000.mac=macaddr > e1000.vlan=vlan > e1000.netdev=netdev > > particularly helpful. Not your fault, outside the scope of this > patch. > Right, you get strange "X=X" output most of the time, but with print_options for enum types you actually get this: $ x86_64-softmmu/qemu-system-x86_64 -device ccid-card-emulated,? ccid-card-emulated.backend=nss-emulated/certificates That's actually parsable. Of course I agree with Anthony that having a json (QMP) interface with properly quoted strings (here I don't take care of backslashes in the EnumTable names for instance) would be much better. > >> > >> * data points to an EnumTable, which is a map string <-> number. Thus, > >> the actual enumeration is attached to the property declaration, not > >> the property type (in programming languages, we commonly attach it to > >> the type, not the variable declaration). Since it's a table it can be > >> used for multiple properties with minimal fuss. Works for me. > >> > >> What if we want to enumerate values of fields with types other than > >> uint32_t? > >> > >> C enumeration types, in particular. Tricky, because width and > >> signedness of enum types is implementation-defined, and different enum > >> types may differ there. > >> > > > > I specifically used uint32_t expecting it to work for many uses. It would > > be better to allow an arbitrary type, or just not require specifying the > > type but getting it from the enum itself (using typeof?). But then you > > can't have a single EnumTable because it's type is now dependent on the > > enumeration type (of course I could resort to macros, but I don't want to > > go there). > > That's what I meant when I called it "tricky". > > Still, having an enum property that cannot be used with enumeration > types is kind of sad, isn't it? > > >> Perhaps what we really need is a way to define arbitrary integer type > >> properties with an EnumTable attached. > >> > > > > This sounds more promising. So you would have an EnumTableU32 etc and > > DEFINE_PROP_{UINT8,..}_ENUM which takes an extra EnumTable of the correct > > type, to be defined inline maybe so user doesn't actually declare it (like > > no one declares Property thanks to the DEFINE_PROP_ macros). > > Sounds like what I have in mind. Care to explore it? > > One EnumTable should do, just make its member value wide enough. > Ok, I can try that. Sounds like it should work. > Note to maintainer: we don't have to get enum properties 100% right and > polished before we can commit this series. >