On 17.06.2025 01:39, Stefano Stabellini wrote: > On Mon, 16 Jun 2025, Alejandro Vallejo wrote: >> On Mon Jun 16, 2025 at 10:00 AM CEST, Julien Grall wrote: >>> Hi, >>> >>> On 13/06/2025 16:13, Alejandro Vallejo wrote: >>>> Without picking CONFIG_HAS_DEVICE_TREE. >>>> >>>> In order to do that. Allow CONFIG_DOM0LESS_BOOT to enable a subset >>>> of the common/device-tree/ directory. >>> > x86 doesn't want dom0less-build.c,> as that's tightly integrated >>> still to the ARM way of building domains. >>> >>> I don't understand this argument. dom0less-build.c was moved to common >>> and it will soon be used by RISC-V. This raises the question what's so >>> special with x86? >> >> That's 2 separate matters: >> >> 1. dom0less-build.c not being compiled in. >> 2. CONFIG_DOM0LESS_BOOT enabling use of DT code without >> CONFIG_HAS_DEVICE_TREE. >> >> (1) is a matter of not wanting to boil the ocean upfront. The way x86 and >> everyone else build domains is just different and duplicated in non-trivially >> consolidable ways. The goal here is to enable the domain builders in any arch >> to use the same backbone. I don't want to go the extra mile just yet to unify >> domain construction (though in time I will want to). >> >> (2) has to do with compiling OUT things I really cannot have around. Anything >> involving devices described in a DT must not exist on x86, because it has no >> concept of a "struct device". >> >> My intent is/was to repurpose CONFIG_HAS_DEVICE_TREE to mean "this hypervisor >> goes on a platform that gives a platform-describing DT". On x86 that's given >> by >> DSDT/SSDTs with ACPI. > > Alejandro is suggesting two levels of Device Tree support: > > - full DT support, including device discovery via DT > - minimal DT support, for the dom0less/hyperlaunch configuration > > Reading this series, it looks reasonable to me, at least as a stepping > stone. I think it is expected that the kind of DT support needed by an > architecture like ARM or RISC-V is different from the one needed by an > architecture like x86. Of course we might be able to align things even > more in the future but as of today I think it is reasonable to > distinguish between the two. > > That said, we might want to consider renaming or changing the kconfig > options. For instance: > > - CONFIG_HAS_DEVICE_TREE -> enable minimal DT support > - CONFIG_DT_DEVICE_DISCOVERY -> device discovery via DT > > In this model, all architectures would have CONFIG_HAS_DEVICE_TREE,
In which case - do we still need HAS_DEVICE_TREE? Jan > but > only ARM and RISC-V would have CONFIG_DT_DEVICE_DISCOVERY.
