On Fri, 2017-05-05 at 10:48 +0200, Christoph Hellwig wrote: > On Fri, May 05, 2017 at 11:44:16AM +0300, Amir Goldstein wrote: > > How about moving this typedef to linux/uuid.h. > > Yes, I think eventually we want that, but for now I tried to keep > it local to XFS. uuid.h already is a mess with uuid_be/uuid_le and > struct uuid_v1. > > I think I'll need to do a series on that first, but this might > run into conflicts with the work that Andy is doing at the moment. Christoph, I can wait a bit and re-do my patch if we settle down data types and function name space. I would really get rid of the mess with UUIDs/GUIDs we have in kernel (but I'm not FS expert, so, I didn't touch that area at all). > > It's weird to have a non xfs_ prefixed typedef as it was > > and placing it here is even more weird. > > We do have a few typedefs like that, but maybe we should eventually > clean them up. > > > Yes, only xfs uses uuid_t right now, but this could mark the > > intentions > > in a central place, so other code can follow suit (i.e. libnvdimm) > > and > > start using uuid_t as well. > > I think libnvdimm would be guid_t. Yes. EFI, ACPI, this one are the users of uuid_le. AFAIR EFI defines type as efi_guid_t. > > > If this is acceptable by Andy, I can re-post my series based on top > > of this one to hoist uuid_t and the rest of the xfs helpers to > > linux/uuid.h. > > Sure. There actually are very few users of uuid_be at the moment, > so it might be a good opportunity to just kill if off ASAP. Agreed. > uuid_le might take a little more time if it's really worth it. We may leave the type and helpers, introduce better ones and encourage new code to use them instead. -- Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
