Re: [PATCH 12/19] x86: define DPS root partition type UUIDs

From: Vincent Mailhol

Date: Mon Jun 15 2026 - 16:21:04 EST


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