Re: [Xen-devel] [PATCH 1/2] xen/xsm: Introduce new boot parameter xsm

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.07.18 at 10:39, <xin.li@xxxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Monday, July 2, 2018 4:25 PM
>> >>> On 02.07.18 at 09:34, <xin.li@xxxxxxxxxx> wrote:
>> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >> Sent: Friday, June 29, 2018 6:05 PM
>> >> >>> On 29.06.18 at 11:47, <andrew.cooper3@xxxxxxxxxx> wrote:
>> >> > On 29/06/18 10:28, Xin Li wrote:
>> >> >> --- a/docs/misc/xen-command-line.markdown
>> >> >> +++ b/docs/misc/xen-command-line.markdown
>> >> >> @@ -865,6 +865,19 @@ hardware domain is architecture dependent.
>> >> >>  Note that specifying zero as domU value means zero, while for
>> >> >> dom0 it means  to use the default.
>> >> >>
>> >> >> +### xsm
>> >> >> +> `= dummy | silo | flask`
>> >> >
>> >> > This should be just "dummy | flask" in this patch, and extended
>> >> > with silo in the next path.  Also, options in this file should be
>> >> > sorted alphabetically, so ### xsm should be near the end, rather than
>> beside flask.
>> >> >
>> >> >> +
>> >> >> +> Default: `dummy`
>> >> >> +
>> >> >> +Specify which XSM module should be enabled.  This option is only
>> >> >> +available if the hypervisor was compiled with XSM support.
>> >> >> +
>> >> >> +* `dummy`: this is the default choice.  No special restriction will be
>> applied.
>> >> >> +  it's also used when XSM is compiled out.
>> >> >> +enum xsm_bootparam __read_mostly xsm_bootparam =
>> >> >> +XSM_BOOTPARAM_DUMMY;
>> >>
>> >> So why "dummy" instead of "none" (or one of the boolean false strings)?
>> >
>> > It seems dummy is not fully stub. (some check by XSM_* classification)
>> > So we want to keep this "dummy" check, and override it.
>> 
>> Right, except that "dummy", while a reasonable name internally to the
>> implementation, is at least of questionable use/meaning as a part of a
>> command line option.
> is it better to keep them the same?

Well, I'm not entirely sure, hence I've made the original remark in the
first place. Command line options should be reasonably meaningful to
those potentially having to use / remember them, so there are cases
where they're better not in 1:1 relationship with naming in source code.
If "none" isn't applicable, how about "basic", "trivial", or "simple"?

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel