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

[Jan Beulich <jbeulich@xxxxxxxx>]

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? Have many "ramdisk"s? Even if some of them serve
an entirely different purpose? 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).

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

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

Jan