On Thu, Jul 18, 2019 at 07:39:51AM +0200, Christoph Hellwig wrote: > On Wed, Jul 17, 2019 at 05:37:06PM +0200, David Sterba wrote: > > > This entire patch because of BTRFS maintainers, they didn't want the > > > explicit > > > casts. Maybe something has been changed, I dunno. > > > > No change on our side. The uuids are u8 in the on-disk structures, that > > will stay. The uuid functions use a different type so the casts have to > > be added, that's clear. The question is if it's up to the API to provide > > functions that take u8, or btrfs code to put typecasts everywhere or > > carry own wrappers that do that. > > So why do you insist on the u8 for the on-disk format? uuid_t is > defined in RFC4122 as a stable format, and one of the two origins of > our uuid_t infrastructure is the XFS code, where it is used for the > on-disk format. What is different in btrfs?
As I replied to v1 (https://lore.kernel.org/linux-btrfs/20190121181841.gj2...@twin.jikos.cz/) I like the simple types in the on-disk structure definitions and that the amount of bytes occupied by the member is obvious. Use of guid_t would need to include linux/uuid.h in the UAPI btrfs headers (that now only include linux/types.h and linux/ioctl.h). This pollutes the namespace as there's also the user-space uuid library that provides the same type, so I can't say that's totally safe. > > Specifically for uuid, the endianness might matter, so that we use the > > raw buffers makes things more explicit. > > u8 arrays hide the endianess, while the RFC4122 UUID is very clearly > defined as having big endian fields where they are bigger than a byte. So we'll use the proper accessors for the raw buffer that's by definition of btrfs format in little endian order, like cpu_to_le and similar. I really try to see what the uuid/guid types would bring but so far see only problems we don't have and the remaining reason is a matter of style/preference/consistency. If you are concerned about uuid API cleanness then we can add the helpers to btrfs. I offered that as an option before, but pushing a typedef to on-disk structures does not feel right given what we have now.
