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

["Daniel P. Smith" <dpsmith@apertussolutions.com>]

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.

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