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

["Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx>
> > + * Copyright (c) 2024 Christopher Clark <christopher.w.clark@xxxxxxxxx>
> > + */
> > +
> > +#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