On 1/30/25 08:45, Jan Beulich wrote:
On 26.12.2024 17:57, Daniel P. Smith wrote:
@@ -596,9 +597,10 @@ int __init dom0_setup_permissions(struct domain *d)
return rc;
}
-int __init construct_dom0(struct boot_info *bi, struct domain *d)
+int __init construct_dom0(struct boot_domain *bd)
Pointer-to-const? Domain construction should only be consuming data
supplied, I expect.
--- /dev/null
+++ b/xen/arch/x86/include/asm/bootdomain.h
Maybe boot-domain.h? Or was that suggested before and discarded for
whatever reason?
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (c) 2024 Apertus Solutions, LLC
+ * Author: Daniel P. Smith <dpsm...@apertussolutions.com>
+ * Copyright (c) 2024 Christopher Clark <christopher.w.cl...@gmail.com>
+ */
+
+#ifndef __XEN_X86_BOOTDOMAIN_H__
+#define __XEN_X86_BOOTDOMAIN_H__
+
+struct boot_domain {
+ struct boot_module *kernel;
+ struct boot_module *ramdisk;
"ramdisk" is Linux-centric, I think. Can we name this more generically?
"module" perhaps, despite it then being the same name as we use for the
modules Xen is passed?
Ramdisk is not a linux-centric, take OpenBSD for example [1]. Calling
the field "module" is a recipe for confusion. Especially considering
that we are more or less providing a lightweight version of the
toolstack interface which use the name ramdisk.
[1] https://openbsd.fandom.com/wiki/Creating_a_custom_OpenBSD_RAM_disk
Also, are consumers of this struct supposed to be able to modify what
the pointers point to? I'd expect they aren't, in which case const will
want adding here, too.
Jan
