public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] nvme: use uuid_t in nvme_ns
@ 2017-06-12  9:12 Johannes Thumshirn
  2017-06-12  9:50 ` Andy Shevchenko
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Johannes Thumshirn @ 2017-06-12  9:12 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Andy Shevchenko, Linux NVMe Mailinglist, Linux Kernel Mailinglist,
	Johannes Thumshirn

struct nvme_ns still uses u u8 uuid[16], change it to using uuid_t and
use the UUID API.

Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
---
 drivers/nvme/host/core.c | 8 ++++----
 drivers/nvme/host/nvme.h | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index c427a7fc31ae..838523441bdb 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -699,7 +699,7 @@ static int nvme_identify_ns_descs(struct nvme_ns *ns, unsigned nsid)
 				goto free_data;
 			}
 			len = NVME_NIDT_UUID_LEN;
-			memcpy(ns->uuid, data + pos + sizeof(*cur), len);
+			uuid_copy(&ns->uuid, data + pos + sizeof(*cur));
 			break;
 		default:
 			/* Skip unnkown types */
@@ -1895,12 +1895,12 @@ static ssize_t uuid_show(struct device *dev, struct device_attribute *attr,
 	/* For backward compatibility expose the NGUID to userspace if
 	 * we have no UUID set
 	 */
-	if (!memchr_inv(ns->uuid, 0, sizeof(ns->uuid))) {
+	if (uuid_is_null(&ns->uuid)) {
 		printk_ratelimited(KERN_WARNING
 				   "No UUID available providing old NGUID\n");
 		return sprintf(buf, "%pU\n", ns->nguid);
 	}
-	return sprintf(buf, "%pU\n", ns->uuid);
+	return sprintf(buf, "%pU\n", &ns->uuid);
 }
 static DEVICE_ATTR(uuid, S_IRUGO, uuid_show, NULL);
 
@@ -1936,7 +1936,7 @@ static umode_t nvme_ns_attrs_are_visible(struct kobject *kobj,
 	struct nvme_ns *ns = nvme_get_ns_from_dev(dev);
 
 	if (a == &dev_attr_uuid.attr) {
-		if (!memchr_inv(ns->uuid, 0, sizeof(ns->uuid)) ||
+		if (uuid_is_null(&ns->uuid) ||
 		    !memchr_inv(ns->nguid, 0, sizeof(ns->nguid)))
 			return 0;
 	}
diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
index 7007521e8194..8ac225882097 100644
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -190,7 +190,7 @@ struct nvme_ns {
 
 	u8 eui[8];
 	u8 nguid[16];
-	u8 uuid[16];
+	uuid_t uuid;
 
 	unsigned ns_id;
 	int lba_shift;
-- 
2.12.3

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] nvme: use uuid_t in nvme_ns
  2017-06-12  9:12 [PATCH v2] nvme: use uuid_t in nvme_ns Johannes Thumshirn
@ 2017-06-12  9:50 ` Andy Shevchenko
  2017-06-12 10:04   ` Johannes Thumshirn
  2017-06-12 16:06 ` Christoph Hellwig
  2017-06-15  8:57 ` Sagi Grimberg
  2 siblings, 1 reply; 7+ messages in thread
From: Andy Shevchenko @ 2017-06-12  9:50 UTC (permalink / raw)
  To: Johannes Thumshirn
  Cc: Christoph Hellwig, Linux NVMe Mailinglist,
	Linux Kernel Mailinglist

On Mon, Jun 12, 2017 at 12:12 PM, Johannes Thumshirn <jthumshirn@suse.de> wrote:
> struct nvme_ns still uses u u8 uuid[16], change it to using uuid_t and
> use the UUID API.

Thanks for an update.

See my further comments below.

>                         len = NVME_NIDT_UUID_LEN;
> -                       memcpy(ns->uuid, data + pos + sizeof(*cur), len);
> +                       uuid_copy(&ns->uuid, data + pos + sizeof(*cur));

So, this reveals two thins:
1) shall we define NVME_NIDT_UUID_LEN to be UUID_LEN or substitute it
completely with the latter?
2) Is the len variable used later in the function?

> -               if (!memchr_inv(ns->uuid, 0, sizeof(ns->uuid)) ||
> +               if (uuid_is_null(&ns->uuid) ||
>                     !memchr_inv(ns->nguid, 0, sizeof(ns->nguid)))

>         u8 nguid[16];
> -       u8 uuid[16];
> +       uuid_t uuid;

Do you plan to switch nguid to be guid_t / uuid_t ?

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] nvme: use uuid_t in nvme_ns
  2017-06-12  9:50 ` Andy Shevchenko
@ 2017-06-12 10:04   ` Johannes Thumshirn
  2017-06-12 11:03     ` Christoph Hellwig
  0 siblings, 1 reply; 7+ messages in thread
From: Johannes Thumshirn @ 2017-06-12 10:04 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Christoph Hellwig, Linux NVMe Mailinglist,
	Linux Kernel Mailinglist

On 06/12/2017 11:50 AM, Andy Shevchenko wrote:
>>                         len = NVME_NIDT_UUID_LEN;
>> -                       memcpy(ns->uuid, data + pos + sizeof(*cur), len);
>> +                       uuid_copy(&ns->uuid, data + pos + sizeof(*cur));
> 
> So, this reveals two thins:
> 1) shall we define NVME_NIDT_UUID_LEN to be UUID_LEN or substitute it
> completely with the latter?

No, we have NVME_NIDT_UUID_LEN but also NVME_NIDT_NGUID_LEN and
NVME_NIDT_EUI64_LEN.

> 2) Is the len variable used later in the function?

Yes, we have to iterate the buffer by len, which can (currently) be
either 8 or 16 bytes. New types which may emerge someday in the future
might have a different length.

> 
>> -               if (!memchr_inv(ns->uuid, 0, sizeof(ns->uuid)) ||
>> +               if (uuid_is_null(&ns->uuid) ||
>>                     !memchr_inv(ns->nguid, 0, sizeof(ns->nguid)))
> 
>>         u8 nguid[16];
>> -       u8 uuid[16];
>> +       uuid_t uuid;
> 
> Do you plan to switch nguid to be guid_t / uuid_t ?
> 

I'm not sure the NVMe NGUID is the same as a GUID (a.k.a little endian
UUID). Quoting from the spec:

"This field uses the EUI-64 based 16-byte designator format. Bytes
114:112 contain the 24-bit Organizationally Unique Identifier (OUI)
value assigned by the IEEE Registration Authority. Bytes 119:115 contain
an extension identifer assigned by the corresponding organization. Bytes
111:104 contain the vendor specific extension identifier assigned by the
corresponding organization. See the IEEE EUI-64 guidelines for more
information."

But maybe Christoph can clarify it.

Byte,
	Johannes
-- 
Johannes Thumshirn                                          Storage
jthumshirn@suse.de                                +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] nvme: use uuid_t in nvme_ns
  2017-06-12 10:04   ` Johannes Thumshirn
@ 2017-06-12 11:03     ` Christoph Hellwig
  2017-06-12 13:11       ` Andy Shevchenko
  0 siblings, 1 reply; 7+ messages in thread
From: Christoph Hellwig @ 2017-06-12 11:03 UTC (permalink / raw)
  To: Johannes Thumshirn
  Cc: Andy Shevchenko, Christoph Hellwig, Linux NVMe Mailinglist,
	Linux Kernel Mailinglist

On Mon, Jun 12, 2017 at 12:04:18PM +0200, Johannes Thumshirn wrote:
> > So, this reveals two thins:
> > 1) shall we define NVME_NIDT_UUID_LEN to be UUID_LEN or substitute it
> > completely with the latter?
> 
> No, we have NVME_NIDT_UUID_LEN but also NVME_NIDT_NGUID_LEN and
> NVME_NIDT_EUI64_LEN.

Yeah, and I'd rather keep the defines for fields defined in the spec
in nvme.h

> I'm not sure the NVMe NGUID is the same as a GUID (a.k.a little endian
> UUID). Quoting from the spec:

It's not at all, the field just has a very unfortunate name in the
spec.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] nvme: use uuid_t in nvme_ns
  2017-06-12 11:03     ` Christoph Hellwig
@ 2017-06-12 13:11       ` Andy Shevchenko
  0 siblings, 0 replies; 7+ messages in thread
From: Andy Shevchenko @ 2017-06-12 13:11 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Johannes Thumshirn, Linux NVMe Mailinglist,
	Linux Kernel Mailinglist

On Mon, Jun 12, 2017 at 2:03 PM, Christoph Hellwig <hch@lst.de> wrote:
> On Mon, Jun 12, 2017 at 12:04:18PM +0200, Johannes Thumshirn wrote:
>> > So, this reveals two thins:
>> > 1) shall we define NVME_NIDT_UUID_LEN to be UUID_LEN or substitute it
>> > completely with the latter?
>>
>> No, we have NVME_NIDT_UUID_LEN but also NVME_NIDT_NGUID_LEN and
>> NVME_NIDT_EUI64_LEN.
>
> Yeah, and I'd rather keep the defines for fields defined in the spec
> in nvme.h
>
>> I'm not sure the NVMe NGUID is the same as a GUID (a.k.a little endian
>> UUID). Quoting from the spec:
>
> It's not at all, the field just has a very unfortunate name in the
> spec.

Thanks for explanations.

So, wrt that
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] nvme: use uuid_t in nvme_ns
  2017-06-12  9:12 [PATCH v2] nvme: use uuid_t in nvme_ns Johannes Thumshirn
  2017-06-12  9:50 ` Andy Shevchenko
@ 2017-06-12 16:06 ` Christoph Hellwig
  2017-06-15  8:57 ` Sagi Grimberg
  2 siblings, 0 replies; 7+ messages in thread
From: Christoph Hellwig @ 2017-06-12 16:06 UTC (permalink / raw)
  To: Johannes Thumshirn
  Cc: Christoph Hellwig, Andy Shevchenko, Linux NVMe Mailinglist,
	Linux Kernel Mailinglist

On Mon, Jun 12, 2017 at 11:12:40AM +0200, Johannes Thumshirn wrote:
> struct nvme_ns still uses u u8 uuid[16], change it to using uuid_t and
> use the UUID API.
> 
> Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>

Thanks, folded into the two patches originall introducing the code.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] nvme: use uuid_t in nvme_ns
  2017-06-12  9:12 [PATCH v2] nvme: use uuid_t in nvme_ns Johannes Thumshirn
  2017-06-12  9:50 ` Andy Shevchenko
  2017-06-12 16:06 ` Christoph Hellwig
@ 2017-06-15  8:57 ` Sagi Grimberg
  2 siblings, 0 replies; 7+ messages in thread
From: Sagi Grimberg @ 2017-06-15  8:57 UTC (permalink / raw)
  To: Johannes Thumshirn, Christoph Hellwig
  Cc: Andy Shevchenko, Linux Kernel Mailinglist, Linux NVMe Mailinglist

Reviewed-by: Sagi Grimberg <sagi@grimberg.me>

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2017-06-15  8:57 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-06-12  9:12 [PATCH v2] nvme: use uuid_t in nvme_ns Johannes Thumshirn
2017-06-12  9:50 ` Andy Shevchenko
2017-06-12 10:04   ` Johannes Thumshirn
2017-06-12 11:03     ` Christoph Hellwig
2017-06-12 13:11       ` Andy Shevchenko
2017-06-12 16:06 ` Christoph Hellwig
2017-06-15  8:57 ` Sagi Grimberg

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox