[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241004171340.v2.1.I938c91d10e454e841fdf5d64499a8ae8514dc004@changeid>
Date: Fri, 4 Oct 2024 17:13:43 -0700
From: Douglas Anderson <dianders@...omium.org>
To: Jens Axboe <axboe@...nel.dk>,
Al Viro <viro@...iv.linux.org.uk>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
Kyle Fortin <kyle.fortin@...cle.com>,
Douglas Anderson <dianders@...gle.com>,
Douglas Anderson <dianders@...omium.org>,
Christian Brauner <brauner@...nel.org>,
Christian Heusel <christian@...sel.eu>,
Jan Kara <jack@...e.cz>,
Li Lingfeng <lilingfeng3@...wei.com>,
Ming Lei <ming.lei@...hat.com>,
Riyan Dhiman <riyandhiman14@...il.com>,
linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: [PATCH v2] block: add partition uuid into uevent as "PARTUUID"
From: Konstantin Khlebnikov <khlebnikov@...dex-team.ru>
Both most common formats have uuid in addition to partition name:
GPT: standard uuid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
DOS: 4 byte disk signature and 1 byte partition xxxxxxxx-xx
Tools from util-linux use the same notation for them.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@...dex-team.ru>
Reviewed-by: Kyle Fortin <kyle.fortin@...cle.com>
[dianders: rebased to modern kernels]
Signed-off-by: Douglas Anderson <dianders@...gle.com>
Signed-off-by: Douglas Anderson <dianders@...omium.org>
---
I found myself needing the PARTUUID from userspace recently and it
seems like pretty much all of the solutions involve a lot of code or
including some userspace libraries to solve this for you. This is less
than ideal when you're running from an initrd and want to keep things
simple.
Given that the kernel has PARTUUID handling already and needs to keep
track of it for using it in "root=" matching, it seems silly not to
expose it, so I wrote a patch for it.
After I wrote the 2 line patch to expose the UUID, I thought to search
the internet and found an old patch where someone had written what
amounts to the same two lines [1], so I'm grabbing the old patch and
resending as a v2. I'm keeping the Reviewed-by even though I rebased
the patch (adjusted for file moves / name changes) since it's a tiny
patch and the concept is identical to the old patch.
Crossing my fingers that this looks OK to land.
[1] https://lore.kernel.org/r/150729013610.744480.1644359289262914898.stgit@buzz
Changes in v2:
- Rebased
block/partitions/core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/block/partitions/core.c b/block/partitions/core.c
index 5bd7a603092e..aa54c1f4eaa5 100644
--- a/block/partitions/core.c
+++ b/block/partitions/core.c
@@ -253,6 +253,8 @@ static int part_uevent(const struct device *dev, struct kobj_uevent_env *env)
add_uevent_var(env, "PARTN=%u", bdev_partno(part));
if (part->bd_meta_info && part->bd_meta_info->volname[0])
add_uevent_var(env, "PARTNAME=%s", part->bd_meta_info->volname);
+ if (part->bd_meta_info && part->bd_meta_info->uuid[0])
+ add_uevent_var(env, "PARTUUID=%s", part->bd_meta_info->uuid);
return 0;
}
--
2.47.0.rc0.187.ge670bccf7e-goog
Powered by blists - more mailing lists