Re: [PATCH v4 10/12] xen: Rename CONFIG_HAS_DEVICE_TREE to CONFIG_HAS_DEVICE_TREE_DISCOVERY

[Jan Beulich <jbeulich@xxxxxxxx>]

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