From: Christoph Hellwig <hch@lst.de>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
linux-xfs <linux-xfs@vger.kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 2/3] xfs: use uuid_be to implement the uuid_t type
Date: Wed, 10 May 2017 14:01:19 +0200 [thread overview]
Message-ID: <20170510120119.GA20271@lst.de> (raw)
In-Reply-To: <CAOQ4uxh_gAUDiCY6yHcTiXRTBzKZv7R7PquAXRzztxRE0yb0wQ@mail.gmail.com>
On Wed, May 10, 2017 at 11:39:27AM +0300, Amir Goldstein wrote:
> To avoid stepping over each other toes, I propose the following work sequence:
I agree on the list, but I've started a tree that has a slightly different
sequence:
(1) renamed uuid_be to uuid_t and uuid_le to guid_t, but keep the old
name for compat for now.
Including these items from your list:
> - Create helper variants uuid_cmp()/uuid_gen()/uuid_to_bin()
(2): kill uuid_v1 by adding a union to uuid_t that has the v1 meaning
(and maybe more in the future)
(3) > This patch set by Christoph:
> - re-define xfs's uuid_t as uuid_be (this patch)
> - more xfs uuid cleanups
(4): > V3 of 'hoist xfs uuid helpers' by me:
> - hoist uuid_t typedef to uuid.h
> - hoist helpers uuid_equal()/uuid_copy() to uuid.h
> - create helper uuid_is_null()
> - convert xfs to use the new uuid_is_null()
(but now moved over the to plain uuid_t type)
(5) > Promote uuid_t to VFS and filesystems (I can do it):
> - Convert sb->s_uuid to uuid_t
> - Convert some sample fs (tmpfs, ext2, ext4, ..) to uuid_t
> - Use uuid_copy() and uuid_gen() where due
And the rest for latter
> Kill off uuid_be (I can do it):
> - Convery uuid_be users to uuid_t and uuid_ helpers
> - Kill off uuid_be and uuid_be_ helpers
>
> Kill off generate_random_uuid (Christoph?):
> - Not sure what you're intentions are wrt to all users that use
> this helper to initialize a char[16] var?
They really should be converted to either uuid_t or guid_t, or
just use prandom_bytes if they really aren't either a UUID or GUID
> Maybe repeat the uuid_be->uuid_t process with uuid_le->guid_t (Andy?):
> - I don't think any of the above interferes with your work to convert
> ACPI to uuid_le?
> - You can actually start this work in parallel to uuid_be->uuid_t, because
> it will create trivial merge conflicts that we can easily sort out
> on the common
> development branch
With my work I'm right now at item (5) of my list, I'll send it out
later this afternoon.
next prev parent reply other threads:[~2017-05-10 12:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-05 7:57 XFS UUID cleanups Christoph Hellwig
2017-05-05 7:57 ` [PATCH 1/3] xfs: use uuid_copy() helper to abstract uuid_t Christoph Hellwig
2017-05-05 7:57 ` [PATCH 2/3] xfs: use uuid_be to implement the uuid_t type Christoph Hellwig
2017-05-05 8:44 ` Amir Goldstein
2017-05-05 8:48 ` Christoph Hellwig
2017-05-05 9:42 ` Andy Shevchenko
2017-05-05 9:56 ` Christoph Hellwig
2017-05-05 10:06 ` Andy Shevchenko
2017-05-05 10:10 ` Christoph Hellwig
2017-05-10 8:39 ` Amir Goldstein
2017-05-10 12:01 ` Christoph Hellwig [this message]
2017-05-10 12:54 ` Andy Shevchenko
2017-05-10 14:15 ` Christoph Hellwig
2017-05-05 7:57 ` [PATCH 3/3] xfs: remove uuid_getnodeuniq and xfs_uu_t Christoph Hellwig
2017-05-05 8:27 ` 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=20170510120119.GA20271@lst.de \
--to=hch@lst.de \
--cc=amir73il@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=dan.j.williams@intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
/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.