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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 16 Jun 2025, Alejandro Vallejo wrote:
> 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.

Yeah, as it looks like not introducing HAS_DEVICE_TREE on x86 is causing
confusion, maybe it is better to add HAS_DEVICE_TREE to all arches and
use a different kconfig to say "this architecture supports device
discovery via DT", such as CONFIG_HAS_DT_DEVICES or
CONFIG_DT_DEVICE_DISCOVERY.