All of lore.kernel.org
 help / color / mirror / Atom feed
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?


  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.