Re: [Qemu-devel] [PATCH 03/16] qdev-properties: add PROP_TYPE_ENUM

[Alon Levy <alevy@redhat.com>]

On Mon, Feb 07, 2011 at 04:27:21PM +0200, Alon Levy wrote:
> On Mon, Feb 07, 2011 at 03:00:25PM +0100, Markus Armbruster wrote:
> > Alon Levy <alevy@redhat.com> 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 <alevy@redhat.com> 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 <alevy@redhat.com>
> > >> > ---
> > >> >  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, "<enum %d>", 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.
> 

Changed my mind - Since libvirt is happy with a string, and this is not something
I really have time to pursue, and Anthony is making a better solution IIUC, I'm
dropping this.

> > Note to maintainer: we don't have to get enum properties 100% right and
> > polished before we can commit this series.
> > 
>