From: Mike Snitzer <snitzer@redhat.com>
To: John Dorminy <jdorminy@redhat.com>
Cc: dm-devel@redhat.com, agk@redhat.com
Subject: Re: dm: expose dm_copy_name_and_uuid()
Date: Mon, 3 Feb 2020 11:54:02 -0500 [thread overview]
Message-ID: <20200203165402.GA11874@redhat.com> (raw)
In-Reply-To: <20200201005524.23405-1-jdorminy@redhat.com>
On Fri, Jan 31 2020 at 7:55pm -0500,
John Dorminy <jdorminy@redhat.com> wrote:
> While dm_device_name() returns the MAJOR:MINOR numbers of a device,
> some targets would like to know the pretty name of a device, and
> some targets would like to know the uuid expected for the device.
>
> The MAJOR:MINOR name is useful for logging, but printing the long
> name of the device can make it easier for the user to correlate
> messages with the device names they know in userspace.
>
> The UUID can be useful for devices which store a UUID on disk, and
> would like to verify the on-disk UUID matches the UUID known by DM.
>
> dm_copy_name_and_uuid() appears to be the only way to get at the
> pretty name and the UUID at present, and this change exports the
> function for use by GPLd modules.
>
> Signed-off-by: John Dorminy <jdorminy@redhat.com>
> ---
> drivers/md/dm-ioctl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c
> index 1e03bc89e20f..711a46015696 100644
> --- a/drivers/md/dm-ioctl.c
> +++ b/drivers/md/dm-ioctl.c
> @@ -2018,7 +2018,7 @@ int dm_copy_name_and_uuid(struct mapped_device *md, char *name, char *uuid)
>
> return r;
> }
> -
> +EXPORT_SYMBOL_GPL(dm_copy_name_and_uuid);
>
> /**
> * dm_early_create - create a mapped device in early boot.
> --
> 2.20.1
These are already available to userspace via sysfs, e.g.:
# dmsetup ls
test-test (253:0)
# cat /sys/block/dm-0/dm/name
test-test
# cat /sys/block/dm-0/dm/uuid
LVM-IFFqf0id2DX3IgGmu6izzJW1rBoWmsC61hwGobtrD60aCMh6zJwK3uiYUS6rbNoY
Verification of the UUID that a target happens to store in its ondisk
metadata seems like it'd best be done by userspace, _before_ activating
the DM device, no? Or are you saying that the target would do this
verification as part of its .ctr method?
Anyway, I'm fine with exporting it.. just think the proposed usecases
are not a "slam-dunk" for why you need it.
next prev parent reply other threads:[~2020-02-03 16:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-01 0:55 [PATCH] dm: expose dm_copy_name_and_uuid() John Dorminy
2020-02-03 16:54 ` Mike Snitzer [this message]
2020-02-07 0:28 ` John Dorminy
2020-02-07 1:24 ` Alasdair G Kergon
2020-02-07 1:42 ` Alasdair G Kergon
2020-02-07 3:19 ` John Dorminy
2020-02-07 17:33 ` Mike Snitzer
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=20200203165402.GA11874@redhat.com \
--to=snitzer@redhat.com \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=jdorminy@redhat.com \
/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.