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. The other
potential modules that could be passed in will need to be able to be
coexist with a ramdisk module being passed. The immediate examples I can
point to are, an SELinux policy file or a guest device tree. I'm not too
familiar, perhaps a Zephyr guest may only take a guest DT, but a Linux
guest may take an initrd and a DT.
v/r,
dps
