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

[Jan Beulich <jbeulich@suse.com>]

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.

Jan