Re: [PATCH v3 13/14] xen/dt: Allow CONFIG_DOM0LESS_BOOT to include device-tree/

[Alejandro Vallejo <agarciav@xxxxxxx>]

On Mon Jun 16, 2025 at 8:55 AM CEST, Jan Beulich wrote:
> On 13.06.2025 17:13, Alejandro Vallejo wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -14,6 +14,7 @@ config CORE_PARKING
>>  
>>  config DOM0LESS_BOOT
>>      bool "Dom0less boot support" if EXPERT
>> +    select LIBFDT
>>      depends on HAS_DOM0LESS && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS
>>      default y
>>      help
>
> Nit: Imo it is good practice to have the select-s after the "depends on",
> and perhaps also after any default(s).
>
>> --- a/xen/common/Makefile
>> +++ b/xen/common/Makefile
>> @@ -8,7 +8,7 @@ obj-y += cpu.o
>>  obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
>>  obj-$(CONFIG_HAS_DEVICE_TREE) += device.o
>>  obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
>> -obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/
>> +obj-$(firstword $(CONFIG_HAS_DEVICE_TREE) $(CONFIG_DOM0LESS_BOOT)) += 
>> device-tree/
>
> Why not
>
> obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/
> obj-$(CONFIG_DOM0LESS_BOOT) += device-tree/
>
> as we have it in a few similar situations?

Because I wasn't sure the build system would swallow it. If you claim it does, 
sure.
I think the "firstword" version is clearer, but I don't mind.

>
> And why would the duplication be needed in the first place? Shouldn't
> DOM0LESS_BOOT imply HAS_DEVICE_TREE? Sadly the description once again
> only says what is intended, but not why. And the dependency is actually
> visible in patch context above, in the hunk altering xen/common/Kconfig.
>
> Jan

After this series the idea is that CONFIG_HAS_DEVICE_TREE means a platform
in which platform resources (memory, devices, etc) are described on DTs.

While x86 ends up understanding DTs to the extent that it's able to parse
and extract "xen,domain" nodes, it's not capable of much more than that. The
distinction is important because making x86 understand general DT (devices, IRQs
and memory) would be far too invasive and not very helpful.

I can rename it to CONFIG_HAS_PLATFORM_DT or CONFIG_HAS_DT_DEVICES, or anything
else if you (or anyone else) have any ideas.

TL;DR: It's to still be able to compile-out the bits x86 cannot use in the DT
machinery.

Cheers,
Alejandro