[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Alejandro Vallejo <agarciav@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>
  • From: Alejandro Vallejo <agarciav@xxxxxxx>
  • Date: Mon, 14 Apr 2025 18:27:15 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9D/VHH+3jIcuMbjxTn/E8UCJN1HiyWgTHG2f3o1OSCA=; b=GmPJeCIyajMZnAj4Q8gVUmQ7f24oJBvTb5AK4Xazc83Y2np7xFODDOvufS8/MRgeFO7jMhdZJksah3/GkMjk84r6jRMHa08048f9KXqVe/uxg615LCIrhadUrIwxrBwlAWAPoddruZVEGy304rWcreKaATWgB3zTaaWS55mhnOnT3JA9pidOj73v40GxTWF/W4q77g1S5il4KED6g2Lh0ThcoGyUeCZ07M1Pi0FEywUpZLCVo1VzbvtF9w2xBx0mo2Bj4/qanOu1tRPmGpQbtboejqucD5JuUwJeGb3q9KlEYfa7pq+4hLmdQTm5kmhbLaVd4t1Pw4FjUKY2QZQF2Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kM99XIj02TX9N89pffEVuY4loT0OANsVYdkuTi/o/5pTKb/qV5CoTKUBjOnMwhiKK0YsxMqSY+LtEj3uVV/+aF10DMtn7vhBQdGqNqMknFXW3usH8dLjcDo2oA5Sd2epAy6tHz3bP6TO3XJCWWyN5xETPhgKFCNuoApJFkxexdwD6kBi/V5nUH4wJjgIN3ZNzwHyMKnLkQQE4MQquEUnWG9g03IhCNHc+fymwI6WRAEk4nsbB1cdGNoGFd5RIrPuof0ooFRTL33HZxdAzUlDI2+rupLApybuRyTtK1kt/Qy48bYjcNiMltPk04ILJbnSgKs/JFWZ/jf5YpyKd5vSjg==
  • Cc: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>, Jason Andryuk <jason.andryuk@xxxxxxx>, Xenia Ragiadakou <xenia.ragiadakou@xxxxxxx>, "Stefano Stabellini" <sstabellini@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 14 Apr 2025 17:27:33 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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

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.

I'm for the time being leaving things as they are (because it is a pain
to change these things) until we settle on something.

Cheers,
Alejandro



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.