All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer
@ 2021-04-15 14:37 ` Andy Shevchenko
  0 siblings, 0 replies; 14+ messages in thread
From: Andy Shevchenko @ 2021-04-15 14:37 UTC (permalink / raw)
  To: Andy Shevchenko, linux-nvdimm, linux-kernel
  Cc: Dan Williams, Vishal Verma, Dave Jiang, Ira Weiny

Strictly speaking the comparison between guid_t and raw buffer
is not correct. Return to plain memcmp() since the data structures
haven't changed to use uuid_t / guid_t the current state of affairs
is inconsistent. Either it should be changed altogether or left
as is.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/nvdimm/btt_devs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/nvdimm/btt_devs.c b/drivers/nvdimm/btt_devs.c
index 05feb97e11ce..82bcd2e86a18 100644
--- a/drivers/nvdimm/btt_devs.c
+++ b/drivers/nvdimm/btt_devs.c
@@ -244,13 +244,14 @@ struct device *nd_btt_create(struct nd_region *nd_region)
  */
 bool nd_btt_arena_is_valid(struct nd_btt *nd_btt, struct btt_sb *super)
 {
+	static const u8 null_uuid[16];
 	const u8 *parent_uuid = nd_dev_to_uuid(&nd_btt->ndns->dev);
 	u64 checksum;
 
 	if (memcmp(super->signature, BTT_SIG, BTT_SIG_LEN) != 0)
 		return false;
 
-	if (!guid_is_null((guid_t *)&super->parent_uuid))
+	if (memcmp(super->parent_uuid, null_uuid, 16) != 0)
 		if (memcmp(super->parent_uuid, parent_uuid, 16) != 0)
 			return false;
 
-- 
2.30.2
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

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

* [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer
@ 2021-04-15 14:37 ` Andy Shevchenko
  0 siblings, 0 replies; 14+ messages in thread
From: Andy Shevchenko @ 2021-04-15 14:37 UTC (permalink / raw)
  To: Andy Shevchenko, linux-nvdimm, linux-kernel
  Cc: Dan Williams, Vishal Verma, Dave Jiang, Ira Weiny

Strictly speaking the comparison between guid_t and raw buffer
is not correct. Return to plain memcmp() since the data structures
haven't changed to use uuid_t / guid_t the current state of affairs
is inconsistent. Either it should be changed altogether or left
as is.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/nvdimm/btt_devs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/nvdimm/btt_devs.c b/drivers/nvdimm/btt_devs.c
index 05feb97e11ce..82bcd2e86a18 100644
--- a/drivers/nvdimm/btt_devs.c
+++ b/drivers/nvdimm/btt_devs.c
@@ -244,13 +244,14 @@ struct device *nd_btt_create(struct nd_region *nd_region)
  */
 bool nd_btt_arena_is_valid(struct nd_btt *nd_btt, struct btt_sb *super)
 {
+	static const u8 null_uuid[16];
 	const u8 *parent_uuid = nd_dev_to_uuid(&nd_btt->ndns->dev);
 	u64 checksum;
 
 	if (memcmp(super->signature, BTT_SIG, BTT_SIG_LEN) != 0)
 		return false;
 
-	if (!guid_is_null((guid_t *)&super->parent_uuid))
+	if (memcmp(super->parent_uuid, null_uuid, 16) != 0)
 		if (memcmp(super->parent_uuid, parent_uuid, 16) != 0)
 			return false;
 
-- 
2.30.2


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

* Re: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer
  2021-04-15 14:37 ` Andy Shevchenko
@ 2021-04-16 17:36   ` Andy Shevchenko
  -1 siblings, 0 replies; 14+ messages in thread
From: Andy Shevchenko @ 2021-04-16 17:36 UTC (permalink / raw)
  To: linux-nvdimm, linux-kernel
  Cc: Dan Williams, Vishal Verma, Dave Jiang, Ira Weiny

On Thu, Apr 15, 2021 at 05:37:54PM +0300, Andy Shevchenko wrote:
> Strictly speaking the comparison between guid_t and raw buffer
> is not correct. Return to plain memcmp() since the data structures
> haven't changed to use uuid_t / guid_t the current state of affairs
> is inconsistent. Either it should be changed altogether or left
> as is.

Dan, please review this one as well. I think here you may agree with me.

-- 
With Best Regards,
Andy Shevchenko

_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

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

* Re: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer
@ 2021-04-16 17:36   ` Andy Shevchenko
  0 siblings, 0 replies; 14+ messages in thread
From: Andy Shevchenko @ 2021-04-16 17:36 UTC (permalink / raw)
  To: linux-nvdimm, linux-kernel
  Cc: Dan Williams, Vishal Verma, Dave Jiang, Ira Weiny

On Thu, Apr 15, 2021 at 05:37:54PM +0300, Andy Shevchenko wrote:
> Strictly speaking the comparison between guid_t and raw buffer
> is not correct. Return to plain memcmp() since the data structures
> haven't changed to use uuid_t / guid_t the current state of affairs
> is inconsistent. Either it should be changed altogether or left
> as is.

Dan, please review this one as well. I think here you may agree with me.

-- 
With Best Regards,
Andy Shevchenko



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

* Re: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer
  2021-04-16 17:36   ` Andy Shevchenko
@ 2021-04-16 20:08     ` Dan Williams
  -1 siblings, 0 replies; 14+ messages in thread
From: Dan Williams @ 2021-04-16 20:08 UTC (permalink / raw)
  To: Andy Shevchenko; +Cc: linux-nvdimm, Linux Kernel Mailing List, Kaneda, Erik

[ add Erik ]

On Fri, Apr 16, 2021 at 10:36 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Thu, Apr 15, 2021 at 05:37:54PM +0300, Andy Shevchenko wrote:
> > Strictly speaking the comparison between guid_t and raw buffer
> > is not correct. Return to plain memcmp() since the data structures
> > haven't changed to use uuid_t / guid_t the current state of affairs
> > is inconsistent. Either it should be changed altogether or left
> > as is.
>
> Dan, please review this one as well. I think here you may agree with me.

You know, this is all a problem because ACPICA is using a raw buffer.

Erik, would it be possible to use the guid_t type in ACPICA? That
would allow NFIT to drop some ugly casts.
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

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

* Re: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer
@ 2021-04-16 20:08     ` Dan Williams
  0 siblings, 0 replies; 14+ messages in thread
From: Dan Williams @ 2021-04-16 20:08 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: linux-nvdimm, Linux Kernel Mailing List, Vishal Verma,
	Dave Jiang, Ira Weiny, Kaneda, Erik

[ add Erik ]

On Fri, Apr 16, 2021 at 10:36 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Thu, Apr 15, 2021 at 05:37:54PM +0300, Andy Shevchenko wrote:
> > Strictly speaking the comparison between guid_t and raw buffer
> > is not correct. Return to plain memcmp() since the data structures
> > haven't changed to use uuid_t / guid_t the current state of affairs
> > is inconsistent. Either it should be changed altogether or left
> > as is.
>
> Dan, please review this one as well. I think here you may agree with me.

You know, this is all a problem because ACPICA is using a raw buffer.

Erik, would it be possible to use the guid_t type in ACPICA? That
would allow NFIT to drop some ugly casts.

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

* Re: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer
  2021-04-16 20:08     ` Dan Williams
@ 2021-04-16 20:42       ` Andy Shevchenko
  -1 siblings, 0 replies; 14+ messages in thread
From: Andy Shevchenko @ 2021-04-16 20:42 UTC (permalink / raw)
  To: Dan Williams; +Cc: linux-nvdimm, Linux Kernel Mailing List, Kaneda, Erik

On Fri, Apr 16, 2021 at 01:08:06PM -0700, Dan Williams wrote:
> [ add Erik ]
> 
> On Fri, Apr 16, 2021 at 10:36 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Thu, Apr 15, 2021 at 05:37:54PM +0300, Andy Shevchenko wrote:
> > > Strictly speaking the comparison between guid_t and raw buffer
> > > is not correct. Return to plain memcmp() since the data structures
> > > haven't changed to use uuid_t / guid_t the current state of affairs
> > > is inconsistent. Either it should be changed altogether or left
> > > as is.
> >
> > Dan, please review this one as well. I think here you may agree with me.
> 
> You know, this is all a problem because ACPICA is using a raw buffer.

And this is fine. It might be any other representation as well.

> Erik, would it be possible to use the guid_t type in ACPICA? That
> would allow NFIT to drop some ugly casts.

guid_t is internal kernel type. If we ever decide to deviate from the current
representation it wouldn't be possible in case a 3rd party is using it 1:1
(via typedef or so).

-- 
With Best Regards,
Andy Shevchenko

_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

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

* Re: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer
@ 2021-04-16 20:42       ` Andy Shevchenko
  0 siblings, 0 replies; 14+ messages in thread
From: Andy Shevchenko @ 2021-04-16 20:42 UTC (permalink / raw)
  To: Dan Williams
  Cc: linux-nvdimm, Linux Kernel Mailing List, Vishal Verma,
	Dave Jiang, Ira Weiny, Kaneda, Erik

On Fri, Apr 16, 2021 at 01:08:06PM -0700, Dan Williams wrote:
> [ add Erik ]
> 
> On Fri, Apr 16, 2021 at 10:36 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Thu, Apr 15, 2021 at 05:37:54PM +0300, Andy Shevchenko wrote:
> > > Strictly speaking the comparison between guid_t and raw buffer
> > > is not correct. Return to plain memcmp() since the data structures
> > > haven't changed to use uuid_t / guid_t the current state of affairs
> > > is inconsistent. Either it should be changed altogether or left
> > > as is.
> >
> > Dan, please review this one as well. I think here you may agree with me.
> 
> You know, this is all a problem because ACPICA is using a raw buffer.

And this is fine. It might be any other representation as well.

> Erik, would it be possible to use the guid_t type in ACPICA? That
> would allow NFIT to drop some ugly casts.

guid_t is internal kernel type. If we ever decide to deviate from the current
representation it wouldn't be possible in case a 3rd party is using it 1:1
(via typedef or so).

-- 
With Best Regards,
Andy Shevchenko



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

* Re: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer
  2021-04-16 20:42       ` Andy Shevchenko
@ 2021-04-16 22:08         ` Dan Williams
  -1 siblings, 0 replies; 14+ messages in thread
From: Dan Williams @ 2021-04-16 22:08 UTC (permalink / raw)
  To: Andy Shevchenko; +Cc: linux-nvdimm, Linux Kernel Mailing List, Kaneda, Erik

On Fri, Apr 16, 2021 at 1:42 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Fri, Apr 16, 2021 at 01:08:06PM -0700, Dan Williams wrote:
> > [ add Erik ]
> >
> > On Fri, Apr 16, 2021 at 10:36 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > >
> > > On Thu, Apr 15, 2021 at 05:37:54PM +0300, Andy Shevchenko wrote:
> > > > Strictly speaking the comparison between guid_t and raw buffer
> > > > is not correct. Return to plain memcmp() since the data structures
> > > > haven't changed to use uuid_t / guid_t the current state of affairs
> > > > is inconsistent. Either it should be changed altogether or left
> > > > as is.
> > >
> > > Dan, please review this one as well. I think here you may agree with me.
> >
> > You know, this is all a problem because ACPICA is using a raw buffer.
>
> And this is fine. It might be any other representation as well.
>
> > Erik, would it be possible to use the guid_t type in ACPICA? That
> > would allow NFIT to drop some ugly casts.
>
> guid_t is internal kernel type. If we ever decide to deviate from the current
> representation it wouldn't be possible in case a 3rd party is using it 1:1
> (via typedef or so).

I'm thinking something like ACPICA defining that space as a union with
the correct typing just for Linux.
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

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

* Re: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer
@ 2021-04-16 22:08         ` Dan Williams
  0 siblings, 0 replies; 14+ messages in thread
From: Dan Williams @ 2021-04-16 22:08 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: linux-nvdimm, Linux Kernel Mailing List, Vishal Verma,
	Dave Jiang, Ira Weiny, Kaneda, Erik

On Fri, Apr 16, 2021 at 1:42 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Fri, Apr 16, 2021 at 01:08:06PM -0700, Dan Williams wrote:
> > [ add Erik ]
> >
> > On Fri, Apr 16, 2021 at 10:36 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > >
> > > On Thu, Apr 15, 2021 at 05:37:54PM +0300, Andy Shevchenko wrote:
> > > > Strictly speaking the comparison between guid_t and raw buffer
> > > > is not correct. Return to plain memcmp() since the data structures
> > > > haven't changed to use uuid_t / guid_t the current state of affairs
> > > > is inconsistent. Either it should be changed altogether or left
> > > > as is.
> > >
> > > Dan, please review this one as well. I think here you may agree with me.
> >
> > You know, this is all a problem because ACPICA is using a raw buffer.
>
> And this is fine. It might be any other representation as well.
>
> > Erik, would it be possible to use the guid_t type in ACPICA? That
> > would allow NFIT to drop some ugly casts.
>
> guid_t is internal kernel type. If we ever decide to deviate from the current
> representation it wouldn't be possible in case a 3rd party is using it 1:1
> (via typedef or so).

I'm thinking something like ACPICA defining that space as a union with
the correct typing just for Linux.

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

* RE: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer
  2021-04-16 22:08         ` Dan Williams
@ 2021-04-19 22:56           ` Kaneda, Erik
  -1 siblings, 0 replies; 14+ messages in thread
From: Kaneda, Erik @ 2021-04-19 22:56 UTC (permalink / raw)
  To: Williams, Dan J, Andy Shevchenko, Moore, Robert, Wysocki, Rafael J
  Cc: linux-nvdimm, Linux Kernel Mailing List, Verma, Vishal L, Jiang,
	Dave, Weiny, Ira

+Bob and Rafael

> -----Original Message-----
> From: Dan Williams <dan.j.williams@intel.com>
> Sent: Friday, April 16, 2021 3:09 PM
> To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: linux-nvdimm <linux-nvdimm@lists.01.org>; Linux Kernel Mailing List
> <linux-kernel@vger.kernel.org>; Verma, Vishal L
> <vishal.l.verma@intel.com>; Jiang, Dave <dave.jiang@intel.com>; Weiny, Ira
> <ira.weiny@intel.com>; Kaneda, Erik <erik.kaneda@intel.com>
> Subject: Re: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw
> buffer
> 
> On Fri, Apr 16, 2021 at 1:42 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Fri, Apr 16, 2021 at 01:08:06PM -0700, Dan Williams wrote:
> > > [ add Erik ]
> > >
> > > On Fri, Apr 16, 2021 at 10:36 AM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > >
> > > > On Thu, Apr 15, 2021 at 05:37:54PM +0300, Andy Shevchenko wrote:
> > > > > Strictly speaking the comparison between guid_t and raw buffer
> > > > > is not correct. Return to plain memcmp() since the data structures
> > > > > haven't changed to use uuid_t / guid_t the current state of affairs
> > > > > is inconsistent. Either it should be changed altogether or left
> > > > > as is.
> > > >
> > > > Dan, please review this one as well. I think here you may agree with me.
> > >
> > > You know, this is all a problem because ACPICA is using a raw buffer.
> >
> > And this is fine. It might be any other representation as well.
> >
> > > Erik, would it be possible to use the guid_t type in ACPICA? That
> > > would allow NFIT to drop some ugly casts.
> >
> > guid_t is internal kernel type. If we ever decide to deviate from the current
> > representation it wouldn't be possible in case a 3rd party is using it 1:1
> > (via typedef or so).
> 
Hi Dan,

> I'm thinking something like ACPICA defining that space as a union with
> the correct typing just for Linux.

I'm assuming that you mean using something like guid_t type for ACPI data table fields like NFIT rather than objects returned by ACPI namespace object such as _DSD.

For ACPI data tables, we could to use macros so that different operating systems can provide their own definitions for a guid. For ACPICA, it will expands to a 16-byte array. Linux can have it's own definition that contains a union or their own guid type (guid_t). As long as the OS-supplied definition is 16bytes, I don't think there would be an issue.

Bob, do you have any thoughts on this?
Erik

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

* RE: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer
@ 2021-04-19 22:56           ` Kaneda, Erik
  0 siblings, 0 replies; 14+ messages in thread
From: Kaneda, Erik @ 2021-04-19 22:56 UTC (permalink / raw)
  To: Williams, Dan J, Andy Shevchenko, Moore, Robert, Wysocki, Rafael J
  Cc: linux-nvdimm, Linux Kernel Mailing List

+Bob and Rafael

> -----Original Message-----
> From: Dan Williams <dan.j.williams@intel.com>
> Sent: Friday, April 16, 2021 3:09 PM
> To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: linux-nvdimm <linux-nvdimm@lists.01.org>; Linux Kernel Mailing List
> <linux-kernel@vger.kernel.org>; Verma, Vishal L
> <vishal.l.verma@intel.com>; Jiang, Dave <dave.jiang@intel.com>; Weiny, Ira
> <ira.weiny@intel.com>; Kaneda, Erik <erik.kaneda@intel.com>
> Subject: Re: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw
> buffer
> 
> On Fri, Apr 16, 2021 at 1:42 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Fri, Apr 16, 2021 at 01:08:06PM -0700, Dan Williams wrote:
> > > [ add Erik ]
> > >
> > > On Fri, Apr 16, 2021 at 10:36 AM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > >
> > > > On Thu, Apr 15, 2021 at 05:37:54PM +0300, Andy Shevchenko wrote:
> > > > > Strictly speaking the comparison between guid_t and raw buffer
> > > > > is not correct. Return to plain memcmp() since the data structures
> > > > > haven't changed to use uuid_t / guid_t the current state of affairs
> > > > > is inconsistent. Either it should be changed altogether or left
> > > > > as is.
> > > >
> > > > Dan, please review this one as well. I think here you may agree with me.
> > >
> > > You know, this is all a problem because ACPICA is using a raw buffer.
> >
> > And this is fine. It might be any other representation as well.
> >
> > > Erik, would it be possible to use the guid_t type in ACPICA? That
> > > would allow NFIT to drop some ugly casts.
> >
> > guid_t is internal kernel type. If we ever decide to deviate from the current
> > representation it wouldn't be possible in case a 3rd party is using it 1:1
> > (via typedef or so).
> 
Hi Dan,

> I'm thinking something like ACPICA defining that space as a union with
> the correct typing just for Linux.

I'm assuming that you mean using something like guid_t type for ACPI data table fields like NFIT rather than objects returned by ACPI namespace object such as _DSD.

For ACPI data tables, we could to use macros so that different operating systems can provide their own definitions for a guid. For ACPICA, it will expands to a 16-byte array. Linux can have it's own definition that contains a union or their own guid type (guid_t). As long as the OS-supplied definition is 16bytes, I don't think there would be an issue.

Bob, do you have any thoughts on this?
Erik
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

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

* RE: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer
  2021-04-19 22:56           ` Kaneda, Erik
@ 2021-04-20 15:54             ` Moore, Robert
  -1 siblings, 0 replies; 14+ messages in thread
From: Moore, Robert @ 2021-04-20 15:54 UTC (permalink / raw)
  To: Kaneda, Erik, Williams, Dan J, Andy Shevchenko, Wysocki, Rafael J
  Cc: linux-nvdimm, Linux Kernel Mailing List, Verma, Vishal L, Jiang,
	Dave, Weiny, Ira



-----Original Message-----
From: Kaneda, Erik <erik.kaneda@intel.com> 
Sent: Monday, April 19, 2021 3:56 PM
To: Williams, Dan J <dan.j.williams@intel.com>; Andy Shevchenko <andriy.shevchenko@linux.intel.com>; Moore, Robert <robert.moore@intel.com>; Wysocki, Rafael J <rafael.j.wysocki@intel.com>
Cc: linux-nvdimm <linux-nvdimm@lists.01.org>; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Verma, Vishal L <vishal.l.verma@intel.com>; Jiang, Dave <dave.jiang@intel.com>; Weiny, Ira <ira.weiny@intel.com>
Subject: RE: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer

+Bob and Rafael

> -----Original Message-----
> From: Dan Williams <dan.j.williams@intel.com>
> Sent: Friday, April 16, 2021 3:09 PM
> To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: linux-nvdimm <linux-nvdimm@lists.01.org>; Linux Kernel Mailing 
> List <linux-kernel@vger.kernel.org>; Verma, Vishal L 
> <vishal.l.verma@intel.com>; Jiang, Dave <dave.jiang@intel.com>; Weiny, 
> Ira <ira.weiny@intel.com>; Kaneda, Erik <erik.kaneda@intel.com>
> Subject: Re: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw 
> buffer
> 
> On Fri, Apr 16, 2021 at 1:42 PM Andy Shevchenko 
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Fri, Apr 16, 2021 at 01:08:06PM -0700, Dan Williams wrote:
> > > [ add Erik ]
> > >
> > > On Fri, Apr 16, 2021 at 10:36 AM Andy Shevchenko 
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > >
> > > > On Thu, Apr 15, 2021 at 05:37:54PM +0300, Andy Shevchenko wrote:
> > > > > Strictly speaking the comparison between guid_t and raw buffer 
> > > > > is not correct. Return to plain memcmp() since the data 
> > > > > structures haven't changed to use uuid_t / guid_t the current 
> > > > > state of affairs is inconsistent. Either it should be changed 
> > > > > altogether or left as is.
> > > >
> > > > Dan, please review this one as well. I think here you may agree with me.
> > >
> > > You know, this is all a problem because ACPICA is using a raw buffer.
> >
> > And this is fine. It might be any other representation as well.
> >
> > > Erik, would it be possible to use the guid_t type in ACPICA? That 
> > > would allow NFIT to drop some ugly casts.
> >
> > guid_t is internal kernel type. If we ever decide to deviate from 
> > the current representation it wouldn't be possible in case a 3rd 
> > party is using it 1:1 (via typedef or so).
> 
Hi Dan,

> I'm thinking something like ACPICA defining that space as a union with 
> the correct typing just for Linux.

I'm assuming that you mean using something like guid_t type for ACPI data table fields like NFIT rather than objects returned by ACPI namespace object such as _DSD.

For ACPI data tables, we could to use macros so that different operating systems can provide their own definitions for a guid. For ACPICA, it will expands to a 16-byte array. Linux can have it's own definition that contains a union or their own guid type (guid_t). As long as the OS-supplied definition is 16bytes, I don't think there would be an issue.

Erik,
I don't like to add these kinds of macros, since it is simply another item that needs to be added to port ACPICA to different hosts. (And must be known by the porter.)

Other than that, I suppose we can add such a macro.

Bob, do you have any thoughts on this?
Erik

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

* RE: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer
@ 2021-04-20 15:54             ` Moore, Robert
  0 siblings, 0 replies; 14+ messages in thread
From: Moore, Robert @ 2021-04-20 15:54 UTC (permalink / raw)
  To: Kaneda, Erik, Williams, Dan J, Andy Shevchenko, Wysocki, Rafael J
  Cc: linux-nvdimm, Linux Kernel Mailing List



-----Original Message-----
From: Kaneda, Erik <erik.kaneda@intel.com> 
Sent: Monday, April 19, 2021 3:56 PM
To: Williams, Dan J <dan.j.williams@intel.com>; Andy Shevchenko <andriy.shevchenko@linux.intel.com>; Moore, Robert <robert.moore@intel.com>; Wysocki, Rafael J <rafael.j.wysocki@intel.com>
Cc: linux-nvdimm <linux-nvdimm@lists.01.org>; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Verma, Vishal L <vishal.l.verma@intel.com>; Jiang, Dave <dave.jiang@intel.com>; Weiny, Ira <ira.weiny@intel.com>
Subject: RE: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer

+Bob and Rafael

> -----Original Message-----
> From: Dan Williams <dan.j.williams@intel.com>
> Sent: Friday, April 16, 2021 3:09 PM
> To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: linux-nvdimm <linux-nvdimm@lists.01.org>; Linux Kernel Mailing 
> List <linux-kernel@vger.kernel.org>; Verma, Vishal L 
> <vishal.l.verma@intel.com>; Jiang, Dave <dave.jiang@intel.com>; Weiny, 
> Ira <ira.weiny@intel.com>; Kaneda, Erik <erik.kaneda@intel.com>
> Subject: Re: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw 
> buffer
> 
> On Fri, Apr 16, 2021 at 1:42 PM Andy Shevchenko 
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Fri, Apr 16, 2021 at 01:08:06PM -0700, Dan Williams wrote:
> > > [ add Erik ]
> > >
> > > On Fri, Apr 16, 2021 at 10:36 AM Andy Shevchenko 
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > >
> > > > On Thu, Apr 15, 2021 at 05:37:54PM +0300, Andy Shevchenko wrote:
> > > > > Strictly speaking the comparison between guid_t and raw buffer 
> > > > > is not correct. Return to plain memcmp() since the data 
> > > > > structures haven't changed to use uuid_t / guid_t the current 
> > > > > state of affairs is inconsistent. Either it should be changed 
> > > > > altogether or left as is.
> > > >
> > > > Dan, please review this one as well. I think here you may agree with me.
> > >
> > > You know, this is all a problem because ACPICA is using a raw buffer.
> >
> > And this is fine. It might be any other representation as well.
> >
> > > Erik, would it be possible to use the guid_t type in ACPICA? That 
> > > would allow NFIT to drop some ugly casts.
> >
> > guid_t is internal kernel type. If we ever decide to deviate from 
> > the current representation it wouldn't be possible in case a 3rd 
> > party is using it 1:1 (via typedef or so).
> 
Hi Dan,

> I'm thinking something like ACPICA defining that space as a union with 
> the correct typing just for Linux.

I'm assuming that you mean using something like guid_t type for ACPI data table fields like NFIT rather than objects returned by ACPI namespace object such as _DSD.

For ACPI data tables, we could to use macros so that different operating systems can provide their own definitions for a guid. For ACPICA, it will expands to a 16-byte array. Linux can have it's own definition that contains a union or their own guid type (guid_t). As long as the OS-supplied definition is 16bytes, I don't think there would be an issue.

Erik,
I don't like to add these kinds of macros, since it is simply another item that needs to be added to port ACPICA to different hosts. (And must be known by the porter.)

Other than that, I suppose we can add such a macro.

Bob, do you have any thoughts on this?
Erik
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

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

end of thread, other threads:[~2021-04-20 15:55 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-15 14:37 [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer Andy Shevchenko
2021-04-15 14:37 ` Andy Shevchenko
2021-04-16 17:36 ` Andy Shevchenko
2021-04-16 17:36   ` Andy Shevchenko
2021-04-16 20:08   ` Dan Williams
2021-04-16 20:08     ` Dan Williams
2021-04-16 20:42     ` Andy Shevchenko
2021-04-16 20:42       ` Andy Shevchenko
2021-04-16 22:08       ` Dan Williams
2021-04-16 22:08         ` Dan Williams
2021-04-19 22:56         ` Kaneda, Erik
2021-04-19 22:56           ` Kaneda, Erik
2021-04-20 15:54           ` Moore, Robert
2021-04-20 15:54             ` Moore, Robert

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.