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

On 6/15/26 13:19, Vincent Mailhol wrote:
...
> 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?

Yep, that makes sense to me.

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

That's not ideal, but it's also a completely static thing that will get
written very, very rarely.

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

Yeah, it should be hidden. Anybody that wants to change it for whatever
reason can edit the .config file or hack Kconfig.