All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Amir Goldstein <amir73il@gmail.com>,
	Dan Williams <dan.j.williams@intel.com>
Cc: alsa-devel@alsa-project.org,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	linux-pci@vger.kernel.org,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Christoph Hellwig <hch@lst.de>, Joerg Roedel <joro@8bytes.org>,
	Linux ACPI <linux-acpi@vger.kernel.org>,
	tpmdd-devel@lists.sourceforge.net,
	Ben Skeggs <bskeggs@redhat.com>,
	nouveau@lists.freedesktop.org, linux-mmc@vger.kernel.org,
	Zhang Rui <rui.zhang@intel.com>, Borislav Petkov <bp@suse.de>,
	Yisen Zhuang <yisen.zhuang@huawei.com>,
	Mathias Nyman <mathias.nyman@intel.com>,
	intel-gfx@lists.freedesktop.org, linux-input@vger.kernel.org,
	Mark Brown <broonie@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Felipe Balbi <balbi@kernel.org>,
	Ne
Subject: Re: [PATCH v1] ACPI: Switch to use generic UUID API
Date: Fri, 05 May 2017 12:24:25 +0300	[thread overview]
Message-ID: <1493976265.30052.21.camel@linux.intel.com> (raw)
In-Reply-To: <CAOQ4uxjha8_2_HwgdgBN=G-vNytAW5Gk155E9z8OWyFiGNEZVw@mail.gmail.com>

On Fri, 2017-05-05 at 10:06 +0300, Amir Goldstein wrote:
> On Fri, May 5, 2017 at 9:20 AM, Dan Williams <dan.j.williams@intel.com
> > wrote:
> > On Thu, May 4, 2017 at 2:21 AM, Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:


> > >         for (i = 0; i < NFIT_UUID_MAX; i++)
> > > -               if (memcmp(to_nfit_uuid(i), spa->range_guid, 16)
> > > == 0)
> > > +               if (!uuid_le_cmp_pp(to_nfit_uuid(i), (uuid_le
> > > *)spa->range_guid))
> > 
> > What is _cmp_pp? Why not _compare?

Dan, it's a typo. In this patch it should be just ..._cmp(), which is
already a part of API.

> > 
> 
> I second that.
> 
> Andy,

Amir, just to be clear. This patch can be applied without any addons to
an existing API. Above is just a typo due to rebase in my tree. I will
replace it to just uuid_le_cmp().

> I much rather that you sort out uuid helpers in a way that will
> satisfy the filesystem
> needs (just provide the helpers don't need to convert filesystems
> code).

> The only reason I took a swing at hoisting the xfs uuid helpers is
> because it didn't
> seem like your proposal was going to be posted soon or wasn't going to
> satisfy
> the filesystems use case.

> 
> My opinion now, is that your suggestion is probably much closer to the
> real deal
> than mine.
> 
> IMO, you should acknowledge that the common use case for filesystems
> is
> to handle an opaque char[16] which most likely holds a uuid_be and you
> should provide 'neutral' helpers to satisfy this use case.
> 
> The simplest would be to typedef uuid_t to struct uuid_be and to name
> 'neutral'
> helpers' uuid_cmp/uuid_copy(uuid_t *, uuid_t *), similar to my
> proposal.

> I think with this semantic change, our proposals can reach common
> grounds
> and satisfy a wider group of users (i.e. filesystem developers).
> 
> Christoph also suggested a similar treatment to typedef guid_t to
> struct uuid_le.
> I don't know the use cases enough to comment on that.

We may go this way. But I wouldn't prevent current users of uuid_le to
continue using it without conversion (it may be done case by case after
we settle an API)

So, summarize what Christoph said it will look like

typedef uuid_be uuid_t;
typedef uuid_le guid_t

uuid_cmp() / uuid_copy() / uuid_to_bin() / etc
guid_cmp() / guid_copy() / guid_to_bin() / etc

Correct? Christoph?

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Amir Goldstein <amir73il@gmail.com>,
	Dan Williams <dan.j.williams@intel.com>
Cc: Linux ACPI <linux-acpi@vger.kernel.org>,
	tpmdd-devel@lists.sourceforge.net,
	intel-gfx@lists.freedesktop.org, nouveau@lists.freedesktop.org,
	linux-input@vger.kernel.org, iommu@lists.linux-foundation.org,
	linux-mmc@vger.kernel.org, Netdev <netdev@vger.kernel.org>,
	linux-pci@vger.kernel.org, USB list <linux-usb@vger.kernel.org>,
	alsa-devel@alsa-project.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Borislav Petkov <bp@suse.de>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Ben Skeggs <bskeggs@redhat.com>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Joerg Roedel <joro@8bytes.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Yisen Zhuang <yisen.zhuang@huawei.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Zhang Rui <rui.zhang@intel.com>, Felipe Balbi <balbi@kernel.org>,
	Mathias Nyman <mathias.nyman@intel.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v1] ACPI: Switch to use generic UUID API
Date: Fri, 05 May 2017 12:24:25 +0300	[thread overview]
Message-ID: <1493976265.30052.21.camel@linux.intel.com> (raw)
In-Reply-To: <CAOQ4uxjha8_2_HwgdgBN=G-vNytAW5Gk155E9z8OWyFiGNEZVw@mail.gmail.com>

On Fri, 2017-05-05 at 10:06 +0300, Amir Goldstein wrote:
> On Fri, May 5, 2017 at 9:20 AM, Dan Williams <dan.j.williams@intel.com
> > wrote:
> > On Thu, May 4, 2017 at 2:21 AM, Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:


> > >         for (i = 0; i < NFIT_UUID_MAX; i++)
> > > -               if (memcmp(to_nfit_uuid(i), spa->range_guid, 16)
> > > == 0)
> > > +               if (!uuid_le_cmp_pp(to_nfit_uuid(i), (uuid_le
> > > *)spa->range_guid))
> > 
> > What is _cmp_pp? Why not _compare?

Dan, it's a typo. In this patch it should be just ..._cmp(), which is
already a part of API.

> > 
> 
> I second that.
> 
> Andy,

Amir, just to be clear. This patch can be applied without any addons to
an existing API. Above is just a typo due to rebase in my tree. I will
replace it to just uuid_le_cmp().

> I much rather that you sort out uuid helpers in a way that will
> satisfy the filesystem
> needs (just provide the helpers don't need to convert filesystems
> code).

> The only reason I took a swing at hoisting the xfs uuid helpers is
> because it didn't
> seem like your proposal was going to be posted soon or wasn't going to
> satisfy
> the filesystems use case.

> 
> My opinion now, is that your suggestion is probably much closer to the
> real deal
> than mine.
> 
> IMO, you should acknowledge that the common use case for filesystems
> is
> to handle an opaque char[16] which most likely holds a uuid_be and you
> should provide 'neutral' helpers to satisfy this use case.
> 
> The simplest would be to typedef uuid_t to struct uuid_be and to name
> 'neutral'
> helpers' uuid_cmp/uuid_copy(uuid_t *, uuid_t *), similar to my
> proposal.

> I think with this semantic change, our proposals can reach common
> grounds
> and satisfy a wider group of users (i.e. filesystem developers).
> 
> Christoph also suggested a similar treatment to typedef guid_t to
> struct uuid_le.
> I don't know the use cases enough to comment on that.

We may go this way. But I wouldn't prevent current users of uuid_le to
continue using it without conversion (it may be done case by case after
we settle an API)

So, summarize what Christoph said it will look like

typedef uuid_be uuid_t;
typedef uuid_le guid_t

uuid_cmp() / uuid_copy() / uuid_to_bin() / etc
guid_cmp() / guid_copy() / guid_to_bin() / etc

Correct? Christoph?

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

  parent reply	other threads:[~2017-05-05  9:24 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-04  9:21 [PATCH v1] ACPI: Switch to use generic UUID API Andy Shevchenko
2017-05-04  9:21 ` Andy Shevchenko
2017-05-04  9:37 ` Jani Nikula
2017-05-04  9:37   ` Jani Nikula
2017-05-04  9:37   ` Jani Nikula
2017-05-04 12:14 ` Heikki Krogerus
2017-05-04 12:14   ` Heikki Krogerus
2017-05-04 12:46 ` Joerg Roedel
2017-05-04 12:46   ` Joerg Roedel
2017-05-04 12:46   ` Joerg Roedel
2017-05-04 13:51 ` Bjorn Helgaas
2017-05-04 13:51   ` Bjorn Helgaas
2017-05-04 13:51   ` Bjorn Helgaas
2017-05-04 15:29 ` Benjamin Tissoires
2017-05-04 15:29   ` Benjamin Tissoires
2017-05-05  6:04 ` kbuild test robot
2017-05-05  6:04   ` kbuild test robot
2017-05-05  6:04   ` [Intel-gfx] " kbuild test robot
2017-05-05  6:20 ` Dan Williams
2017-05-05  6:20   ` Dan Williams
2017-05-05  6:20   ` Dan Williams
2017-05-05  7:06   ` Amir Goldstein
2017-05-05  7:06     ` Amir Goldstein
2017-05-05  7:06     ` Amir Goldstein
     [not found]     ` <CAOQ4uxjha8_2_HwgdgBN=G-vNytAW5Gk155E9z8OWyFiGNEZVw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-05  7:30       ` Christoph Hellwig
2017-05-05  7:30         ` Christoph Hellwig
2017-05-05  7:30         ` Christoph Hellwig
2017-05-05  9:24     ` Andy Shevchenko [this message]
2017-05-05  9:24       ` Andy Shevchenko
2017-05-05  9:50       ` Amir Goldstein
2017-05-05  9:50         ` Amir Goldstein
2017-05-05  9:57         ` Christoph Hellwig
2017-05-05  9:57           ` Christoph Hellwig
2017-05-05  9:57           ` Christoph Hellwig
2017-05-05 10:02           ` Amir Goldstein
2017-05-05 10:02             ` Amir Goldstein
2017-05-09  7:56 ` Felipe Balbi
2017-05-09  7:56   ` Felipe Balbi
2017-05-09  7:56   ` Felipe Balbi
2017-05-09  8:22 ` Mathias Nyman
2017-05-09  8:22   ` Mathias Nyman
2017-05-10  1:20 ` Zhang Rui
     [not found] ` <20170504092151.88646-1-andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-05-22 19:08   ` Andy Shevchenko
2017-05-22 19:08     ` Andy Shevchenko

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=1493976265.30052.21.camel@linux.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=adrian.hunter@intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=amir73il@gmail.com \
    --cc=balbi@kernel.org \
    --cc=benjamin.tissoires@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=bp@suse.de \
    --cc=broonie@kernel.org \
    --cc=bskeggs@redhat.com \
    --cc=dan.j.williams@intel.com \
    --cc=hch@lst.de \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=joro@8bytes.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=rui.zhang@intel.com \
    --cc=tpmdd-devel@lists.sourceforge.net \
    --cc=yisen.zhuang@huawei.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.