On 23.06.2025 16:19, Alejandro Vallejo wrote: > On Mon Jun 23, 2025 at 3:44 PM CEST, Jan Beulich wrote: >> On 23.06.2025 15:11, Alejandro Vallejo wrote: >>> On Mon Jun 23, 2025 at 9:39 AM CEST, Jan Beulich wrote: >>>> On 20.06.2025 20:28, Alejandro Vallejo wrote: >>>>> Moving forward the idea is for there to be: >>>>> 1. Basic DT support: used by dom0less/hyperlaunch. >>>>> 2. Full DT support: used for device discovery and HW setup. >>>>> >>>>> Rename HAS_DEVICE_TREE to HAS_DEVICE_TREE_DISCOVERY to describe (2), while >>>>> DOM0LESS_BOOT is left to describe (1). >>>> >>>> Considering hyperlaunch this feels wrong to me. Did you consider splitting >>>> HAS_DEVICE_TREE into HAS_DEVICE_TREE_PARSE and HAS_DEVICE_TREE_DISCOVERY, >>>> as I suggested on the committers call? You weren't there, but Stefano said >>>> he was taking notes. >>> >>> Some might've been lost is transit, I admit. I don't remember hearing about >>> a HAS_DEVICE_TREE_PARSE, but it might've very well been me being spotty when >>> syncing with Stefano. >>> >>> Having a special HAS_DEVICE_TREE_PARSE doesn't seem very helpful, as every >>> arch would have it set. >> >> Hmm, yes, we don't want or need that. But then what's option 1 about? That >> shouldn't be "described" by DOM0LESS_BOOT. > > It's about x86 using device_tree/ for hyperlaunch. x86 is the single user that > doesn't need (2) at all. In the x86 case the same selector that picks > >> >>> I'd definitely like for the "enable support to boot >>> several predefined domains from DTB descriptions" to be a single option for >>> both >>> dom0less and hyperlaunch. And be selectable rather than unconditionally >>> selected >>> And ideally move towards a future in which both dom0less and hyperlaunch >>> are one >>> and the same. >>> >>> I can do an early rename s/HAS_DOM0LESS/HAS_PREDEFINED_DOMAINS and s/ >>> DOM0LESS_BOOT/BOOT_PREDEFINED_DOMAINS/ if that helps. I was waiting to do so >>> until x86 gains the ability to boot off a DTB to avoid having help messages >>> describing things not yet on the tree. >> >> I have to admit that it's not clear to me if that would help. As you say, on >> x86 that's not a thing just yet. What I think we need to aim for is to not >> leave the tree in a state that's more confusing than anything else. Even if >> later (which may be much later) things would get tidied again. > > Ok, how about turning it on its head? Seems like we're in agreement with > HAS_DEVICE_TREE_DISCOVERY for Full DT support. There could be a > DEVICE_TREE_PARSE > (no HAS_) that's selected by HAS_DEVICE_TREE_DISCOVERY and DOM0LESS_BOOT. This > allows x86 to deselect it by not picking DOM0LESS_BOOT. > > Note that x86 cannot select DOM0LESS_BOOT yet, but that's how it'd compile-in > hyperlaunch. In the meantime, the tree depends on DEVICE_TREE_PARSE instead > and > device_tree/ is gated by DEVICE_TREE_PARSE only. > > Sounds better?
Yes. Except that in the last sentence of the previous paragraph: What's "the tree"? And in device_tree/ wouldn't we end up with unreachable code on x86 this way (the parts that are needed only by DEVICE_TREE_DISCOVERY)? Jan
