Re: [PATCH v3 11/16] x86/hyperlaunch: locate dom0 initrd with hyperlaunch

[Alejandro Vallejo <agarciav@xxxxxxx>]

On Tue Apr 15, 2025 at 7:17 AM BST, Jan Beulich wrote:
> On 14.04.2025 19:27, Alejandro Vallejo wrote:
>> On Mon Apr 14, 2025 at 6:06 PM BST, Alejandro Vallejo wrote:
>>> On Thu Apr 10, 2025 at 12:34 PM BST, Jan Beulich wrote:
>>>> On 08.04.2025 18:07, Alejandro Vallejo wrote:
>>>>
>>>>> +            printk("  ramdisk: boot module %d\n", idx);
>>>>> +            bi->mods[idx].type = BOOTMOD_RAMDISK;
>>>>> +            bd->module = &bi->mods[idx];
>>>>
>>>> The field's named "module" now, but that now ends up inconsistent with
>>>> naming used elsewhere, as is pretty noticeable here.
>>>
>>> Well, yes. It is confusing. Also, the DTB is called multiboot,ramdisk,
>>> because multiboot,module is already used to detect what nodes are
>>> expressed as multiboot,modules. I'm considering going back and calling
>>> them ramdisk again. If anything, to avoid the ambiguity between
>>> domain modules and multiboot modules. e.g: a kernel is a multiboot
>>> module, but not a domain module.
>> 
>> Particularly when misc/arm/device-tree/booting.txt already states that
>> the initrd for dom0 ought to be provided with the "multiboot,ramdisk"
>> string in the "compatible" prop.  Deviating from that is just going to
>> make it far more annoying to unify arm and x86 in the future.  And
>> calling those ramdisks anything but ramdisk internally is just plain
>> confusing (as evidenced in the current series).
>
> Yet the limitation of this is quite obvious: How would you express
> multiple such items?

With multiple such nodes.

  initrd1 {
      compatible = "multiboot,ramdisk", "multiboot,module"
      module-idx = <2>
  };
  initrd2 {
      compatible = "multiboot,ramdisk", "multiboot,module"
      module-idx = <3>
  };

as is done in dom0less. This is not a hypothetical, it's already
comitted.

> Have many "ramdisk"s?

As many as I require. If I was booting Xen(dom0+initrd) on
Xen(hyperlaunch), that'd be 2 (with Xen passed as the kernel).

> Even if some of them serve an entirely different purpose?

The purpose of a ramdisk/initrd is of no concern to the hypervisor. They are
specially crafted blobs consumed by kernels for purposes of bootstrap.

> See how Linux has gone to tuck together multiple CPIOs, as they can
> have only one thing called "ramdisk" (which, aiui, now no longer truly
> is).

That's an internal Linux matter. If they need 1, we'll pass 1. We do
need several such blobs, because some OSs do need them. Namely, Xen. And
AFAICS we call them modules mostly because (a) Xen does not have the
module infrastructure that Linux has, which would causes ambiguities and
(b) is typically loaded via multiboot, which does call each blob a
module.

>
>> So... how frontally opposed would you be to restoring the ramdisk
>> nomenclature? Also, for ease of rebasing future patches it'd be far
>> nicer to go back to ramdisk rather than reinventing some new name.
>
> Well, I fear I wouldn't ack such a patch. If everyone else agrees
> that "ramdisk" is the best of all names (or at least getting close),
> I'd perhaps mumble over, but let it go in.

Ok... When I send v4 I'll do so keeping the "module" rename. Meanwhile,
I'll try to think of some options. Calling Xen's modules and the booted
kernel modules the same way is just way too confusing.

I take it you have the same dislike for initrd as you do for ramdisk?

>
> (Only partly as a joke: If we dislike "module", how about "blob" or
> some such?)

Better not. Blob makes "kernel" sound like an adjective: Kernel blob.

There might be some other suitable word. I'll think about it.

Cheers,
Alejandro