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" <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? > > 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
