On 4/7/25 03:10, Jan Beulich wrote:
On 05.04.2025 02:04, Daniel P. Smith wrote:
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
Just one other OS also using such a concept doesn't mean much. In fact,
"ramdisk"
isn't quite appropriate a term for Linux nowadays anymore anyway. An initrd can
consist of multiple pieces now, not all of which end up taken as "ramdisk". I
wouldn't insist on "module" as a name, but I continue to think "ramdisk" is
inappropriate. The fact that the toolstack uses the term has historical reasons;
it doesn't mean new code in Xen needs to continue to use that term.
That opening response is very disingenuous and goal post moving. Your
initial comment asserted that it is a Linux only concept, and when met
with another example, you now want to just brush it off.
The fact is that the concept of a ramdisk predates Linux by a
considerable amount, 1979 CP/M introduced the concept. Yes, initrd is a
variation of a ramdisk, which is why the field is not called initrd
(despite that term used elsewhere as a variable name). I would also
point out, as you very well know, Linux's multiple module ramdisk is not
supported by Xen today, nor is there any plan to add it.
The fact is that ramdisk **is** a general term for the specific
capability that the primary supported operating system uses, along with
other operating systems *BSD. As a result the concept is all over the
code base and so it is not at all unreasonable to have an explicit
reference reserved for it.
V/r,
DPS
