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?
Cheers
Vladimir
