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

Re: [Xen-devel] [PATCH v4 3/4] tools: add tools support for Intel CDP



On Fri, 2015-09-25 at 17:53 +0800, He Chen wrote:
> > Quoting the relevant bits of code for clarity:
> >      libxl_psr_cbm_type type = LIBXL_PSR_CBM_TYPE_L3_CBM;
> >     ...
> >     case 'd':
> >         type = LIBXL_PSR_CBM_TYPE_L3_DATA;
> >         opt_data = 1;
> >         break;
> >     case 'c':
> >         type = LIBXL_PSR_CBM_TYPE_L3_CODE;
> >         opt_code = 1;
> >         break;
> >      }
> >  
> >     if (opt_data && opt_code)
> >         type = LIBXL_PSR_CBM_TYPE_L3_CBM;
> > 
> > So the behaviour if -d and -c are given is exactly the same as if
> > neither
> > of them were given, i.e. type = LIBXL_PSR_CBM_TYPE_L3_CBM? Is that
> > correct
> > and intended?
> 
> Yes.
> 
> > If so then I think it would be clearer to only set opt_* during option
> > parsing and then to figure out the correct LIBXL_PSR_CBM_TYPE_*
> > explicitly
> > afterwards, rather than have the code cycle through data->code->cbm.
> > 
> > Or just outlaw passing both -d and -c together since it is confusing
> > and
> > equivalent to passing neither anyway.
> 
> Yes, as you said, if user just passes one option -d (or -c), things would
> be done during option parsing, there is no need to add the if().
> 
> But the key point is that I am not sure how to address outlaw passing
> both
> -d and -c together (is it allowed?). If it is permitted, the behaviour is
> the same as passing neither indeed, and the if() is needed to avoid
> latter
> option overwritting former option.
> 
> What's your suggestion? Sorry, I am a little confused.
> Omit former opiton when both options are given and remove if()?
> Or something else?

I was trying to make one suggestion for restructuring the code and one
design choice to make, let me see if I can clarify.

I think the basic code structure should be:

    libxl_psr_cbm_type type;
    int opt_data = 0, opt_code = 1;
    [...]
    case 'd':
        opt_data = 1;
        break;
    case 'c':
        opt_code = 1;
            break;
[...]

    [... now figure out correct type= based on opt_data + opt+code... ]
Which separates the option parsing from the logic of what they mean.

Then the choice I mentioned is whether passing -c and -d at the same
time is valid or not.

If you want passing both -c and -d at the same time to be invalid then the
code would be something like:

    if (opt_data && opt_code) {
        log error and exit
    } else if (opt_data) {
        type = LIBXL_PSR_CBM_TYPE_L3_DATA;
    } else if (opt_code) {
        type = LIBXL_PSR_CBM_TYPE_L3_CODE;
    else { /* Neither */
        type = LIBXL_PSR_CBM_TYPE_L3_CBM;
    }

If you want passing both -c and -d to be valid and behave like passing
neither then it would be something like:

    if (opt_data && opt_code) {
        type = LIBXL_PSR_CBM_TYPE_L3_CBM;
    } else if
    (opt_data) {
        type = LIBXL_PSR_CBM_TYPE_L3_DATA;
    } else if (opt_code) {
        type =
        LIBXL_PSR_CBM_TYPE_L3_CODE;
    else { /* Neither, same as both */
        type =
        LIBXL_PSR_CBM_TYPE_L3_CBM;
    }

Which one you use is up to you, depending on what you think the most sensible 
semantics are.

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®.