Re: [Qemu-devel] [PATCH 5/6] add visitor for parsing hz[KMG] input string

[mdroth]

On Wed, Dec 05, 2012 at 05:21:50PM -0200, Eduardo Habkost wrote:
> On Wed, Dec 05, 2012 at 11:52:29AM -0600, mdroth wrote:
> > On Tue, Dec 04, 2012 at 05:34:42PM -0200, Eduardo Habkost wrote:
> [...]
> > > diff --git a/qapi/string-input-visitor.c b/qapi/string-input-visitor.c
> > > index 497eb9a..74fe395 100644
> > > --- a/qapi/string-input-visitor.c
> > > +++ b/qapi/string-input-visitor.c
> > > @@ -110,6 +110,27 @@ static void parse_start_optional(Visitor *v, bool 
> > > *present,
> > >      *present = true;
> > >  }
> > >  
> > > +static void parse_type_freq(Visitor *v, int64_t *obj, const char *name,
> > > +                            Error **errp)
> > > +{
> > > +    StringInputVisitor *siv = DO_UPCAST(StringInputVisitor, visitor, v);
> > > +    char *endp = (char *) siv->string;
> > > +    long long val = 0;
> > > +
> > > +    errno = 0;
> > 
> > If this is for strtosz_suffix_unit(), it looks like this is already
> > handled internally and can be dropped. Relic from a previous version
> > that called strtod() directly maybe?
> > 
> > If that's not the case, I think it should be fixed in the called function[s]
> > rather than for each caller.
> > 
> > > +    if (siv->string) {
> > > +        val = strtosz_suffix_unit(siv->string, &endp,
> > > +                             STRTOSZ_DEFSUFFIX_B, 1000);
> > 
> > Specifying 1000 as the unit size will make "1M" == 1000^2 as opposed to
> > 1024^2. Is this intentional?
> 
> I don't know if this is a good idea for a generalx-use visitor, but this is 
> the
> current behavior of "-cpu ...,tsc_freq=1M", that we need to keep for
> compatibility, somehow.
> 
> > 
> > > +    }
> > > +    if (!siv->string || val == -1 || *endp) {
> > > +        error_set(errp, QERR_INVALID_PARAMETER_VALUE, name,
> > > +              "a value representable as a non-negative int64");
> > > +        return;
> > > +    }
> > > +
> > > +    *obj = val;
> > > +}
> > > +
> > >  Visitor *string_input_get_visitor(StringInputVisitor *v)
> > >  {
> > >      return &v->visitor;
> > > @@ -132,6 +153,7 @@ StringInputVisitor *string_input_visitor_new(const 
> > > char *str)
> > >      v->visitor.type_str = parse_type_str;
> > >      v->visitor.type_number = parse_type_number;
> > >      v->visitor.start_optional = parse_start_optional;
> > > +    v->visitor.type_freq = parse_type_freq;
> > 
> > This seems applicable for stuff like -m 1G and potentionally some other
> > properties. We can make it generic later, but if we do end up re-spinning
> > consider something like ->type_unit_suffixed_int(). But I'm not against
> > leaving as is for now since I can't think of a better name for it atm :)
> 
> I thought the visitor was going to support things like "1GHz", but if it's 
> just
> a "suffixed int" with no unit, the name could be changed, I guess.
> 
> But we still have the 1000 vs 1024 problem. On the one hand, it would be
> interesting to make make it consistent and use the same base everywhere.
> On the other hand, I assume we have different command-line options using
> different bases and we'll need to keep compatibility.

If we were to map it to a QAPI schema definition at some point, I'd
imagine it looking something like:

{ 'field_name': { 'type': 'suffixed_int', 'unit': 1000 } }

with 'unit' defaulting to 1024 if unspecified. (I have some patches
floating around as part of the QIDL series for doing more descriptive
QAPI definitions) 

> 
> Must all visitor functions have the
> "function(Visitor *v, obj, const char *name, Error **errp)" signature,
> or can we add additional type-specific arguments? (so we could tell
> the visitor if the default base should be 1000 or 1024)

Visitor functions don't necessarilly have to follow the same basic
signature, so it would be okay to declare it with an extra 'unit' param
and pass that in. We could still hide this behind a visit_type_freq()
wrapper in open-coded visitors as well, I'd just prefer to make the bits
we add to qapi-visit-core.c more general where possible to keep unit
tests and code generation stuff somewhat sane for the core api.

> 
> -- 
> Eduardo
>