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

["Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

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.
V/r,
DPS