[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |