From: Vincent Mailhol <mailhol@kernel.org>
To: Dave Hansen <dave.hansen@intel.com>, 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 22:19:40 +0200 [thread overview]
Message-ID: <ea71a433-fdcc-429d-adce-14e9fb726957@kernel.org> (raw)
In-Reply-To: <03be57ae-0e41-4b8a-adc5-bdd85ccce951@intel.com>
On 15/06/2026 at 18:46, Dave Hansen wrote:
> 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?
I didn't pay much attention to this, but this is a very good point.
The Discoverable Partitions Specification is not clear about this
point. All it has to say is:
On systems *with matching architecture*, the first partition with
this type UUID on the disk containing the active EFI ESP is
automatically mounted to the root directory /.
Does an x86_32 system match an x86_64 partition? Wouldn't make sense.
Does an x86_64 system match an x86_32 partition? Could be.
My feeling is that the intent was an *exact* match. This is supported
by the implementation in systemd which just check against
SD_GPT_ROOT_NATIVE (which corresponds to the exact match).
https://github.com/systemd/systemd/blob/main/src/udev/udev-builtin-blkid.c#L243-L247
*But* there are some hints about a secondary UUID. In my terminal I have:
$ systemd-id128 show root root-secondary
NAME ID
root 4f68bce3e8cd4db196e7fbcaf984b709
root-secondary 44479540f29741b29af7d131d5f0458a
where root is the x86_64 and root-secondary is x86_32. So although I
see no match logic in the code, the ID table have it!
That said, your points make sense to me, and I would be supportive to
allow a search for a secondary UUID as a kernel extension. If we do
so, I think the only constraint should be to make sure that we check
for the exact match first (e.g. check x86_64 type before x86_32 type).
Would that make sense?
> 2. Should the UUIDs be defined in arch code or generic code?
I think that you convinced me to put it in generic code.
> 3. Kconfig or #ifdefs?
I would say Kconfig. If we go for the exact match only, that would be:
CONFIG_DPS_ROOT_PARTITION_TYPE_UUID
If we allow more as an extension, that would become:
- CONFIG_DPS_ROOT_PARTITION_TYPE_UUID for the exact match
- CONFIG_DPS_ROOT_PARTITION_TYPE_UUID_SECONDARY for the compatible
one.
The drawback is that some entries will be in both:
config DPS_ROOT_PARTITION_TYPE_UUID
string
default "4f68bce3-e8cd-4db1-96e7-fbcaf984b709" if X86_64
default "44479540-f297-41b2-9af7-d131d5f0458a" if X86
config DPS_ROOT_PARTITION_TYPE_UUID_SECONDARY
string
default "44479540-f297-41b2-9af7-d131d5f0458a" if X86_64 && COMPAT_32
And I don't think we need more than two.
A bonus question: should those Kconfig entries be hidden? I prefer the
hidden option because it doesn't add that much code and I thought this
was not worth bothering the user with one more menuconfig question.
But I would be happy to change if people this this is worth an
menuconfig entry.
Yours sincerely,
Vincent Mailhol
next prev parent reply other threads:[~2026-06-15 20:19 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
2026-06-15 18:05 ` Matthew Wilcox
2026-06-15 20:39 ` Vincent Mailhol
2026-06-15 20:19 ` Vincent Mailhol [this message]
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=ea71a433-fdcc-429d-adce-14e9fb726957@kernel.org \
--to=mailhol@kernel.org \
--cc=axboe@kernel.dk \
--cc=bp@alien8.de \
--cc=brauner@kernel.org \
--cc=dave.hansen@intel.com \
--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=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.