Re: [PATCH v1 01/18] kconfig: allow configuration of maximum modules

["Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

On 7/20/22 03:27, Jan Beulich wrote:
> On 19.07.2022 19:02, Daniel P. Smith wrote:
>> On 7/19/22 05:32, Jan Beulich wrote:
>>> On 06.07.2022 23:04, Daniel P. Smith wrote:
>>>> --- a/xen/arch/x86/efi/efi-boot.h
>>>> +++ b/xen/arch/x86/efi/efi-boot.h
>>>> @@ -18,7 +18,7 @@ static multiboot_info_t __initdata mbi = {
>>>>   * The array size needs to be one larger than the number of modules we
>>>>   * support - see __start_xen().
>>>>   */
>>>> -static module_t __initdata mb_modules[5];
>>>> +static module_t __initdata mb_modules[CONFIG_NR_BOOTMODS + 1];
>>>
>>> If the build admin selected 1, I'm pretty sure about nothing would work.
>>> I think you want max(5, CONFIG_NR_BOOTMODS) or
>>> max(4, CONFIG_NR_BOOTMODS) + 1 here and ...
>>
>> Actually, I reasoned this out and 1 is in fact a valid value. It would
>> mean Xen + Dom0 Linux kernel with embedded initramfs with no externally
>> loaded XSM policy and no boot time microcode patching. This is a working
>> configuration, but open to debate if it is a desirable configuration.
>> The question is whether it is desired to block someone from building
>> such a configuration, or any number between 1 and 4. If the answer is
>> yes, then why not just set the lower bound of the range in the Kconfig
>> file instead of having to maintain a hard-coded lower bound in a max
>> marco across multiple locations?
> 
> While I'd be fine with the lower bounds being raised, I wouldn't be very
> happy with seeing those lower bounds becoming arch-specific.

Okay, and I am not sure how changing the range in Kconfig would make it
arch-specific. I was not proposing making the existing range conditioned
and having arch specific instances. There is one range, it will have a
lower bound of 4 and the upper bound of 31768.

v/r,
dps