On Wednesday 12 Feb 2020 at 16:24:42 (+0000), Vladimir Murzin wrote:
> Hi,
>
> On 2/12/20 4:10 PM, Ionela Voinescu wrote:
> > Hi Suzuki,
> >
> > On Wednesday 12 Feb 2020 at 11:30:44 (+0000), Suzuki Kuruppassery Poulose wrote:
> >>> +static int __init set_disable_amu(char *str)
> >>> +{
> >>> + int value = 0;
> >>> +
> >>> + disable_amu = get_option(&str, &value) ? !!value : true;
> >> minor nit: You could simply use strtobool(str) here, which accepts:
> >>
> >> disable_amu= [0/1/on/off/y/n]
> >>
> > Yes, this was intentional as I wanted "disable_amu" to be a valid option
> > as well, not only "disable_amu=<option>".
> >
> > If you don't mind I'd like to keep it like this. Currently the use of
> > AMU is enabled by default, and the most common kernel parameter to
> > disable it would be "disable_amu". Allowing "disable_amu=0" is just in
> > case we change the default in the kernel to not support AMU and we'd
> > like platforms to be able to enable it.
> >
>
> Sorry for jumping into thread, but can we avoid negatives into naming which
> accept values? If is always tricky to get expected effect when both are combined.
>
> If value doesn't really mater than can it be just "noamu"?
>
> If value does matter can it be (per Suzuki) amu=[0/1/on/off/y/n]?
>
> Or can you postpone introduction of "just in case" option till that case happens?
>
No worries, thank you very much for the input. I'll change it to
amu=[0/1/on/off/y/n] for clarity.
Thank you,
Ionela.
> Cheers
> Vladimir
