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? > 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.
