[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [v7][PATCH 16/16] tools: parse to enable new rdm policy parameters



Chen, Tiejun writes ("Re: [v7][PATCH 16/16] tools: parse to enable new rdm 
policy parameters"):
> > The first issue (which would really be relevant to the documentation
> > patch) is that the documentation is in a separate commit.  There are
> > sometimes valid reasons for doing this.  I'm not sure if they apply,
> 
> Wei suggested we should organize/spit all patches according to libxl, 
> libxc, xc and xl.

Yes.  I don't want to put you in the middle of a
disagreement/misunderstanding between Wei and me.  This is in any case
a fairly minor issue.

> In this patch head description, maybe I can change something like this
> 
> This patch parses to enable user configurable parameters to specify
> RDM resource and according policies which are defined previously,

That would be good, yes, thanks.

> >> +                }else if ( !strcmp(optkey, "rdm_policy") ) {
> >> +                    if ( !strcmp(tok, "strict") ) {
> >> +                        pcidev->rdm_policy = 
> >> LIBXL_RDM_RESERVE_POLICY_STRICT;
> >> +                    } else if ( !strcmp(tok, "relaxed") ) {
> >> +                        pcidev->rdm_policy = 
> >> LIBXL_RDM_RESERVE_POLICY_RELAXED;
> >> +                    } else {
> >> +                        XLU__PCI_ERR(cfg, "%s is not an valid PCI RDM 
> >> property"
> >> +                                          " policy: 'strict' or 
> >> 'relaxed'.",
> >> +                                     tok);
> >> +                        goto parse_error;
> >> +                    }
> >
> > This section has coding style (whitespace) problems and long lines.
> > If you need to respin, please fix them.
> 
> Are you saying this?
> 
> } else if (  -> }else if (
> } else { -> }else {

Also spurious spaces inside brackets.  Please see CODING_STYLE.

> Additionally I don't found which line is over 80 characters.

Hmm, I see that the longest line is exactly 80.

Of course 80 characters, plus a `+' from a patch, and `>' for email
quoting, makes more than 80: so it has wrap damage on my screen.  You
are right that this conforms to the wording in the style, which says
`75-80'.  So I won't insist on this change (unless I manage to
persuade my comaintainers to strenghten this restriction in the style
guide).

> >> +    for (tok = ptr, end = ptr + strlen(ptr) + 1; ptr < end; ptr++) {
> >> +        switch(state) {
> >> +        case STATE_TYPE:
> >
> > This code is extremely repetitive.
> 
> I just refer to xlu_pci_parse_bdf()

Yes.  I'm afraid that xlu_pci_parse_bdf is a poor example.

> > Really I would prefer that this parsing was done with a miniature flex
> > parser, rather than ad-hoc pointer arithmetic and use of strtok.
> 
> Sorry, could you show this explicitly?

Something like what was done for disk devices.  See libxlu_disk_l.l
for an example.  In this case your code would be a lot less
complicated than what you see there.

After the codefreeze I would probably have some time to write it for
you.  (I think that would be valuable because libxlu_disk_l.l is a
very complicated example, and I want be able to point future
submitters at something simpler.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.