> On 29 Mar 2023, at 13:24, Jan Beulich <[email protected]> wrote:
> 
> On 29.03.2023 14:06, Luca Fancellu wrote:
>>>> @@ -61,7 +62,12 @@ custom_param("dom0_mem", parse_dom0_mem);
>>>> 
>>>> int __init parse_arch_dom0_param(const char *str_begin, const char 
>>>> *str_end)
>>>> {
>>>> -    return -1;
>>>> +    int rc = 0;
>>>> +
>>>> +    if ( sve_parse_dom0_param(str_begin, str_end) < 0 )
>>>> +        rc = -EINVAL;
>>> 
>>> ... can't you call parse_integer() right here? opt_dom0_sve isn't static,
>>> so ought to be accessible here (provided the necessary header was included).
>>> 
>> 
>> Oh ok now I’ve seen why I’m doing this, because ops_dom0_sve is compiled only
>> when CONFIG_ARM64_SVE is enabled, so I’m using sve_parse_dom0_param()
>> that returns negative if that option is not enabled.
>> 
>> Otherwise I should declare ops_dom0_sve anyway, but I should not accept user
>> customization of it if the option is not enabled.
>> 
>> So I thought the use of sve_parse_dom0_param() was the best way to handle 
>> that
> 
> Maybe. But please also pay attention to the existence of no_config_param()
> (as in: consider using it here, which would require the code to live outside
> of sve.c).

Thank you, I didn’t know the existence of no_config_param(), I’ve had a look on 
the
approach, for example in static int __init cf_check parse_cet(const char *s), 
and I’ll do
something similar

> 
> Jan

Reply via email to