| Message ID | 20170518062705.25902-24-hch@lst.de (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On Thu, May 18, 2017 at 9:27 AM, Christoph Hellwig <hch@lst.de> wrote: > Everything uses uuid_t now. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- Excellent! I reviewed the entire series. You may add Reviewed-by: Amir Goldstein <amir73il@gmail.com> to any of the patches as you see fit. Now let's talk about how this is going to be merged. Do you intend to send Linus a pull request? Get those patches merged via someone else's tree? Is this branch listed for linux-next build? The reason I am asking is because this last removal patch should probably be applied near the end of the merge window (?). Because maintainers cannot apply patches with code that uses the new uuid_t to linux-next branches and we don't want linux-next build to fail with new code that uses uuid_be... More to the point, I would like to re-post the patch ("tmpfs: generate random sb->s_uuid") using uuid_gen() instead of generate_random_uuid() as you proposed. Hugh has already acked the intent "once fs is agreed on the way to go" When and how would I have this patch applied? Obvious solution.. can you apply this patch to your branch? Do you need me to re-post it? Thanks for working on this! Amir.
On Thu, May 18, 2017 at 10:57:24AM +0300, Amir Goldstein wrote: > I reviewed the entire series. You may add > Reviewed-by: Amir Goldstein <amir73il@gmail.com> > > to any of the patches as you see fit. Thanks, done! > Now let's talk about how this is going to be merged. > Do you intend to send Linus a pull request? Yes, that might be the best idea. I'm also contemplating listing me plus anyone volunteering (you?, Andy) as maintaines for the uuid code. But first I'll need a few more reviews, at least for the XFS bits. > Get those patches merged via someone else's tree? > Is this branch listed for linux-next build? Not yet. > The reason I am asking is because this last removal patch should probably > be applied near the end of the merge window (?). > Because maintainers cannot apply patches with code that uses the new > uuid_t to linux-next branches and we don't want linux-next build to fail > with new code that uses uuid_be... Yeah, we can probably defer that one for now. > More to the point, I would like to re-post the patch > ("tmpfs: generate random sb->s_uuid") using uuid_gen() > instead of generate_random_uuid() as you proposed. > Hugh has already acked the intent "once fs is agreed on the way to go" > When and how would I have this patch applied? > Obvious solution.. can you apply this patch to your branch? Yes. > Do you need me to re-post it? Please do.
On Thu, 2017-05-18 at 10:56 +0200, Christoph Hellwig wrote: > On Thu, May 18, 2017 at 10:57:24AM +0300, Amir Goldstein wrote: > > I reviewed the entire series. You may add > > Reviewed-by: Amir Goldstein <amir73il@gmail.com> > > > > to any of the patches as you see fit. > > Thanks, done! Similar from my side, FWIW: Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > > Now let's talk about how this is going to be merged. > > Do you intend to send Linus a pull request? > > Yes, that might be the best idea. I'm also contemplating listing > me plus anyone volunteering (you?, Andy) as maintaines for the uuid > code. I would agree to be a designated reviewer for now (too many stuff to follow as a (co-)maintainer). > > The reason I am asking is because this last removal patch should > > probably > > be applied near the end of the merge window (?). > > Because maintainers cannot apply patches with code that uses the new > > uuid_t to linux-next branches and we don't want linux-next build to > > fail > > with new code that uses uuid_be... > > Yeah, we can probably defer that one for now. I would also like to append some of patches from my side, though they are WIP.
diff --git a/include/linux/uuid.h b/include/linux/uuid.h index e8a065035113..6b9a05570565 100644 --- a/include/linux/uuid.h +++ b/include/linux/uuid.h @@ -111,26 +111,12 @@ int guid_to_bin(const char *uuid, guid_t *u); int uuid_to_bin(const char *uuid, uuid_t *u); /* backwards compatibility, don't use in new code */ -typedef uuid_t uuid_be; -#define UUID_BE(a, _b, c, d0, d1, d2, d3, d4, d5, d6, d7) \ - UUID(a, _b, c, d0, d1, d2, d3, d4, d5, d6, d7) -#define NULL_UUID_BE \ - UUID_BE(0x00000000, 0x0000, 0x0000, 0x00, 0x00, 0x00, 0x00, \ - 0x00, 0x00, 0x00, 0x00) - #define uuid_le_gen(u) guid_gen(u) -#define uuid_be_gen(u) uuid_gen(u) #define uuid_le_to_bin(guid, u) guid_to_bin(guid, u) -#define uuid_be_to_bin(uuid, u) uuid_to_bin(uuid, u) static inline int uuid_le_cmp(const guid_t u1, const guid_t u2) { return memcmp(&u1, &u2, sizeof(guid_t)); } -static inline int uuid_be_cmp(const uuid_t u1, const uuid_t u2) -{ - return memcmp(&u1, &u2, sizeof(uuid_t)); -} - #endif
Everything uses uuid_t now. Signed-off-by: Christoph Hellwig <hch@lst.de> --- include/linux/uuid.h | 14 -------------- 1 file changed, 14 deletions(-)