From: Dave Hansen <dave.hansen@intel.com>
To: Vincent Mailhol <mailhol@kernel.org>,
Jens Axboe <axboe@kernel.dk>, Davidlohr Bueso <dave@stgolabs.net>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>
Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org
Subject: Re: [PATCH 12/19] x86: define DPS root partition type UUIDs
Date: Mon, 15 Jun 2026 09:46:41 -0700 [thread overview]
Message-ID: <03be57ae-0e41-4b8a-adc5-bdd85ccce951@intel.com> (raw)
In-Reply-To: <20260615-discoverable-root_partitions-v1-12-39c78fac42e2@kernel.org>
On 6/15/26 09:09, Vincent Mailhol wrote:
> +#ifdef CONFIG_X86_64
> +#define DPS_ROOT_PARTITION_TYPE_UUID "4f68bce3-e8cd-4db1-96e7-fbcaf984b709"
> +#else
> +#define DPS_ROOT_PARTITION_TYPE_UUID "44479540-f297-41b2-9af7-d131d5f0458a"
> +#endif
This doesn't make a whole lot of sense to me. 64-bit kernels can run
32-bit userspace just fine.
But this #ifdef as proposed means that only a 32-bit *OR* 64-bit kernel
can auto-discover a given partition.
I kinda think you should just have an array of strings for these things,
maybe glued together with some preprocessor magic. Logically something
like this:
const char* const uuids[] = {
#ifdef CONFIG_ARM64
"b921b045-1df0-41c3-af44-4c6f280d3fae"
#endif
#ifdef CONFIG_X86_64
"4f68bce3-e8cd-4db1-96e7-fbcaf984b709",
#endif
#if defined(CONFIG_X86) && defined(CONFIG_COMPAT32)
"44479540-f297-41b2-9af7-d131d5f0458a",
#endif
...
};
... and then search the array. I honestly don't think you need to
sprinkle UUIDs all over the architectures.
It could probably also be done almost entirely in Kconfig. This could be
in, say block/partitions/Kconfig, or arch/*/Kconfig:
config DPS_ROOT_PARTITION_TYPE_UUID_1
string
default "4f68bce3-e8cd-4db1-96e7-fbcaf984b709" if X86_64
default "b921b045-1df0-41c3-af44-4c6f280d3fae" if ARM64
...
config DPS_ROOT_PARTITION_TYPE_UUID_2
string
default "44479540-f297-41b2-9af7-..." if X86 && COMPAT_32
const char* const uuids[] = {
#ifdef CONFIG_DPS_ROOT_PARTITION_TYPE_UUID_1
CONFIG_DPS_ROOT_PARTITION_TYPE_UUID_1
#endif
#ifdef CONFIG_DPS_ROOT_PARTITION_TYPE_UUID_2
CONFIG_DPS_ROOT_PARTITION_TYPE_UUID_2
#endif
...
};
There are a lot of ways to do this. I'm just not a super big fan of the
current proposal.
So, boiling it down:
1. Should more than one UUID be supported per kernel build?
2. Should the UUIDs be defined in arch code or generic code?
3. Kconfig or #ifdefs?
next prev parent reply other threads:[~2026-06-15 16:46 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-15 16:08 [PATCH 00/19] init: discoverable root partitions, a.k.a. an omittable "root=" cmdline option Vincent Mailhol
2026-06-15 16:08 ` Vincent Mailhol
2026-06-15 16:08 ` Vincent Mailhol
2026-06-15 16:08 ` [PATCH 01/19] init: add DPS root partition type UUID capability Vincent Mailhol
2026-06-15 16:08 ` [PATCH 02/19] alpha: define DPS root partition type UUID Vincent Mailhol
2026-06-15 16:08 ` [PATCH 03/19] arc: " Vincent Mailhol
2026-06-15 16:08 ` Vincent Mailhol
2026-06-15 16:09 ` [PATCH 04/19] arm: " Vincent Mailhol
2026-06-15 16:09 ` [PATCH 05/19] arm64: " Vincent Mailhol
2026-06-15 16:09 ` [PATCH 06/19] loongarch: " Vincent Mailhol
2026-06-15 16:09 ` [PATCH 07/19] mips: define DPS root partition type UUIDs Vincent Mailhol
2026-06-15 16:09 ` [PATCH 08/19] parisc: define DPS root partition type UUID Vincent Mailhol
2026-06-15 20:02 ` James Bottomley
2026-06-15 20:27 ` Helge Deller
2026-06-15 20:43 ` Vincent Mailhol
2026-06-15 16:09 ` [PATCH 09/19] powerpc: define DPS root partition type UUIDs Vincent Mailhol
2026-06-15 16:09 ` [PATCH 10/19] riscv: " Vincent Mailhol
2026-06-15 16:09 ` Vincent Mailhol
2026-06-15 16:09 ` [PATCH 11/19] s390: " Vincent Mailhol
2026-06-15 16:09 ` [PATCH 12/19] x86: " Vincent Mailhol
2026-06-15 16:46 ` Dave Hansen [this message]
2026-06-15 18:05 ` Matthew Wilcox
2026-06-15 20:39 ` Vincent Mailhol
2026-06-15 20:19 ` Vincent Mailhol
2026-06-16 0:09 ` Dave Hansen
2026-06-15 16:09 ` [PATCH 13/19] block: store GPT partition type UUID Vincent Mailhol
2026-06-15 16:09 ` [PATCH 14/19] block: add early_lookup_bdev_by_type_uuid() Vincent Mailhol
2026-06-15 16:09 ` [PATCH 15/19] block: store GPT attributes as a raw value Vincent Mailhol
2026-06-15 16:09 ` [PATCH 16/19] block: don't discover partition with DPS no-auto GPT attribute Vincent Mailhol
2026-06-15 16:09 ` [PATCH 17/19] init: factor out root device lookup into lookup_root_device() Vincent Mailhol
2026-06-15 16:09 ` [PATCH 18/19] init: discover root by DPS partition type UUID Vincent Mailhol
2026-06-15 16:09 ` [PATCH 19/19] docs: document discoverable root partitions Vincent Mailhol
2026-06-15 17:04 ` [PATCH 00/19] init: discoverable root partitions, a.k.a. an omittable "root=" cmdline option Al Viro
2026-06-15 17:04 ` Al Viro
2026-06-15 17:04 ` Al Viro
2026-06-15 20:33 ` Vincent Mailhol
2026-06-15 20:33 ` Vincent Mailhol
2026-06-15 20:33 ` Vincent Mailhol
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=03be57ae-0e41-4b8a-adc5-bdd85ccce951@intel.com \
--to=dave.hansen@intel.com \
--cc=axboe@kernel.dk \
--cc=bp@alien8.de \
--cc=brauner@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=dave@stgolabs.net \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mailhol@kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.