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

[Jan Beulich <jbeulich@xxxxxxxx>]

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?

Jan