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" <dpsm...@apertussolutions.com> >>>>>> >>>>>> 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 <dpsm...@apertussolutions.com> >>>>>> Reviewed-by: Jason Andryuk <jason.andr...@amd.com> >>>>> >>>>> Acked-by: Jan Beulich <jbeul...@suse.com> >>>> >>>> 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
