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