Re: [PATCH v2 1/3] uuid: Add inline helpers to operate on raw buffers

From: David Sterba <dsterba@suse.cz>
To: Christoph Hellwig <hch@lst.de>
Cc: dsterba@suse.cz,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>,
	Lu Fengqi <lufq.fnst@cn.fujitsu.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2 1/3] uuid: Add inline helpers to operate on raw buffers
Date: Thu, 18 Jul 2019 19:52:02 +0200	[thread overview]
Message-ID: <20190718175202.GK20977@twin.jikos.cz> (raw)
In-Reply-To: <20190718053951.GA18122@lst.de>

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.GJ2900@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.