Re: [PATCH v2 01/15] x86/boot: introduce boot domain

[Jan Beulich <jbeulich@suse.com>]

On 10.04.2025 01:55, Daniel P. Smith wrote:
> 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 <dpsmith@apertussolutions.com>
>>>>> + * Copyright (c) 2024 Christopher Clark <christopher.w.clark@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.

Well, not quite. I deliberately said "..., I think" to indicate the my
horizon. For background, I've originally come from the DOS/Windows and
NetWare worlds, where no such concept ever existed (again, to my
necessarily limited knowledge).

> 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.

I don't understand what you're alluding to here. Xen doesn't itself need
a ramdisk. Nevertheless to perhaps find microcode to load, it peeks into
the (sole) module provided to the Dom0 kernel.

> 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.

Yet then, compared to multiboot, it being just a single module is a
perhaps severe (portability) limitation. And as soon as we talk about
multiple modules, I'm relatively sure you agree that we can't assume
them all to be RAM disk images. See how Xen itself has got Dom0 kernel,
Dom0 initrd, XSM policy, and CPU microcode.

Naming the thing as generically as possible at least clearly indicates
the route to go from 1 to N.

Jan