From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>,
Miklos Szeredi <miklos@szeredi.hu>,
Mimi Zohar <zohar@linux.vnet.ibm.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Richard Weinberger <richard@nod.at>,
"Darrick J . Wong" <darrick.wong@oracle.com>,
Mark Fasheh <mfasheh@versity.com>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-xfs <linux-xfs@vger.kernel.org>,
linux-unionfs@vger.kernel.org,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
David Howells <dhowells@redhat.com>
Subject: Re: [RFC][PATCH] linux/uuid.h: hoist uuid_is_null() helper from libnvdimm
Date: Wed, 03 May 2017 14:00:33 +0300 [thread overview]
Message-ID: <1493809233.30052.1.camel@linux.intel.com> (raw)
In-Reply-To: <CAOQ4uxh4Ysg9Q_K2sK9zefvid3hvzswDKxSa-QTN9_D0fAWvyQ@mail.gmail.com>
On Wed, 2017-05-03 at 13:05 +0300, Amir Goldstein wrote:
> On Wed, May 3, 2017 at 12:13 PM, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Tue, 2017-05-02 at 23:19 +0300, Amir Goldstein wrote:
> > > We need a helper for VFS to check if struct super_block field
> > > s_uuid
> > > was filled by the filesystem, before consumers can use it.
> > >
> > > The libnvdimm code already has a private helper to check if uuid
> > > is
> > > null
> > > and the helper name is not using a private namespace prefix, which
> > > prevents us from using the same helper name as a common function.
> > >
> >
> > Hmm...
> > Have you checked my branch here:
> > https://bitbucket.org/andy-shev/linux/branch/topic%2Fuuid
> > ?
> >
>
> Hi Andy,
>
> No I have not seen your patches. When do you plan to post them?
Some of them had been sent in different series recently and ~year ago.
Some need to be polished and tested first.
So, somewhere in the future for sure.
> > Probably not.
> > I have number of patches to make UUID API used kernel wide.
> >
>
> That looks nice, but I see you did not get to converting many other
> users that represent uuid as u8[16], like libnvdimm, bluetooth,
> various filesystems and users of sb->s_uuid (IMA).
Yes, my main goal is to make ACPI glue layer to use UUID API.
I didn't touch and I won't touch filesystems since it's a huge area
which I have no knowledge of.
For the rest I might be interested to do, but have no time.
>
> > ...including helpers for null UUID check:
> > https://bitbucket.org/andy-shev/linux/commits/79029ebe2c32830f82effc
> > 0f0b
> > 62cce2b6eb7fdb?at=topic/uuid
> >
>
> I wouldn't mind using is_null_uuid_le(sb->s_uuid) myself and that is
> how
> I implemented the test in my current patch set, but I can hear the
> voices of
> those saying that there should be a 'natural' helper uuid_is_null(u8
> *) for the
> users that represent uuid as u8[16] (i.e. filesystems and sb->s_uuid).
u8 * doesn't represent UUID as a type.
Perhaps we need to reflect this in the name of the function somehow.
> Also, I suggest naming your helpers uuid_{le|be}_is_null() to maintain
> the uuid_* naming convention with other helpers you added to uuid.h.
I'm open to a name that satisfies most of us. So, no objections here.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2017-05-03 11:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-02 20:19 [RFC][PATCH] linux/uuid.h: hoist uuid_is_null() helper from libnvdimm Amir Goldstein
2017-05-02 20:57 ` Dan Williams
2017-05-03 9:13 ` Andy Shevchenko
2017-05-03 10:05 ` Amir Goldstein
2017-05-03 11:00 ` Andy Shevchenko [this message]
2017-05-03 12:42 ` Amir Goldstein
2017-05-03 16:35 ` Andy Shevchenko
2017-05-03 17:15 ` Andy Shevchenko
2017-05-03 18:34 ` Amir Goldstein
2017-05-04 8:21 ` Andy Shevchenko
2017-05-04 8:39 ` Amir Goldstein
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=1493809233.30052.1.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=amir73il@gmail.com \
--cc=dan.j.williams@intel.com \
--cc=darrick.wong@oracle.com \
--cc=dhowells@redhat.com \
--cc=hch@lst.de \
--cc=konrad.wilk@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mfasheh@versity.com \
--cc=miklos@szeredi.hu \
--cc=richard@nod.at \
--cc=viro@zeniv.linux.org.uk \
--cc=zohar@linux.vnet.ibm.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.