Re: [PATCH v4 02/13] kconfig: introduce domain builder config options

[Alejandro Vallejo <agarciav@amd.com>]

On Thu Apr 17, 2025 at 4:00 PM BST, Jan Beulich wrote:
> On 17.04.2025 14:48, Alejandro Vallejo wrote:
>> --- /dev/null
>> +++ b/xen/common/domain-builder/Kconfig
>> @@ -0,0 +1,18 @@
>> +
>> +menu "Domain Builder Features"
>> +depends on HAS_BOOT_INFO
>
> That is, what's going to further be added here will not ...
>
>> +config DOMAIN_BUILDER
>
> ...depend on this, but just on HAS_BOOT_INFO? Seems not very likely, but
> I'll be looking forward to learn what the plans are.

CONFIG_HAS_BOOT_INFO has nothing to do with future plans.  The domain
builder is tightly integrated with the boot_info infrastructure and
cannot be used (or linked) unless the arch-specific definitions are
present. It cannot function without it. And this movement from arch/ to
common/ forces this new Kconfig to gate core.c on boot_info existing
(because it's in asm/bootinfo.h atm). I _COULD_ also move the boot_info
elsewhere, but without a drive to actually use it, that seems a bit
pointless.

HAS_BOOT_INFO && !DOMAIN_BUILDER still links core.c, because that
contains the common initialiser for boot_info.

>
> Also, if the entire contents here is to depend on HAS_BOOT_INFO, can't
> the "source" line pulling in this Kconfig be put inside "if HAS_BOOT_INFO"?
> That would centralize definition and use of that symbol to a single file.

Sure.

>
>> +	bool "Domain builder (UNSUPPORTED)" if UNSUPPORTED
>> +	select LIBFDT
>> +	help
>> +	  Xen has a built-in mechanisms to automatically construct domains
>> +	  (like dom0) during the boot phase. The domain builder is an enhanced
>> +	  form of that mechanism to enable constructing predefined domains
>> +	  described on a flattened device tree.
>
> I'm not a native speaker, but (perhaps because of that) "on" here reads
> odd. More logical to me would be "by" or "via".
>
> Jan

Yes, you're right. I just felt the previous help wasn't very helpful
unless you knew in advance what you were toggling. Jason's more concrete
suggestion in the following reply sounds reasonable too, so I'll just
copy that on resend.

Cheers,
Alejandro