Re: [PATCH v3 01/16] x86/boot: introduce boot domain

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.04.2025 16:00, Daniel P. Smith wrote:
> 
> 
> V/r,
> Daniel P. Smith
> Apertus Solutions, LLC
> 
> On 4/16/25 09:33, Jan Beulich wrote:
>> On 16.04.2025 15:02, Daniel P. Smith wrote:
>>> On 4/10/25 16:56, Jason Andryuk wrote:
>>>> On 2025-04-10 11:01, Jan Beulich wrote:
>>>>> On 10.04.2025 15:09, Daniel P. Smith wrote:
>>>>>> On 4/9/25 02:24, Jan Beulich wrote:
>>>>>>> On 08.04.2025 18:07, Alejandro Vallejo wrote:
>>>>>>>> From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
>>>>>>>>
>>>>>>>> To begin moving toward allowing the hypervisor to construct more
>>>>>>>> than one
>>>>>>>> domain at boot, a container is needed for a domain's build
>>>>>>>> information.
>>>>>>>> Introduce a new header, <xen/asm/bootdomain.h>, that contains the
>>>>>>>> initial
>>>>>>>> struct boot_domain that encapsulate the build information for a
>>>>>>>> domain.
>>>>>>>>
>>>>>>>> Add a kernel and ramdisk boot module reference along with a struct
>>>>>>>> domain
>>>>>>>> reference to the new struct boot_domain. This allows a struct
>>>>>>>> boot_domain
>>>>>>>> reference to be the only parameter necessary to pass down through
>>>>>>>> the domain
>>>>>>>> construction call chain.
>>>>>>>>
>>>>>>>> Signed-off-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>
>>>>>>>> Reviewed-by: Jason Andryuk <jason.andryuk@xxxxxxx>
>>>>>>>
>>>>>>> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>>>>
>>>>>> I have to object because the meaningless rename is going cause
>>>>>> significant pain in the rebase of the follow-on series for no improved
>>>>>> code clarity.
>>>>>
>>>>> Sorry, then an incremental patch undoing the rename that happened (with
>>>>> appropriate justification) will need proposing - the patch here has gone
>>>>> in already.
>>>>
>>>> Coming from a Linux background, ramdisk seemed more natural to me.  But
>>>> looking at hvm_start_info, the fields are called module there.  And
>>>> since we shouldn't tie this to the Linux naming, the more generic
>>>> "module" name seemed fine to me.
>>>
>>> Again, as I have stated, ramdisk is not a Linux only concept. In fact,
>>> as Jan points out, initrd/initramfs are Linux specific implementations
>>> of a ramdisk for which Xen doesn't even fully support. I am inclined to
>>> ask the inverse of why hvm_start_info uses the name module. But that
>>> aside, let's consider the fact that the field is only populated by the
>>> device tree when a module type of BOOTMOD_RAMDISK is matched. And all
>>> the uses of the field are when its value is stored into a local variable
>>> called initrd.
>>>
>>> Though the biggest irony is that generally obtuse abstraction are
>>> routinely blocked unless there is a tangible future case. Yet none was
>>> offered in the comment. Thus on that principle alone, a request for a
>>> tangible future use should have been requested and provided for the
>>> change to be considered.
>>
>> Does it even need to be a _future_ use here? Aren't you working on
>> abstracting domain creation, suitable (in principle) for all architectures?
>> Isn't therefore a more generic name (as "module" is) preferable over a more
>> specific one?
> 
> Yes we are trying to build a future capability, but my point is let's 
> consider all possible known OS's start up today. What other boot module 
> could potentially be passed in that is exclusive of a ramdisk, thus 
> allowing a multiplex of the field. And the answer is none.

Is it? What if you are to start a nested Xen with its own kernel, initrd
and perhaps even an XSM policy "module"? Or anything else that is multi-
module capable (possibly but not necessarily because of having started
out as multiboot)?

Jan