From: Christoph Hellwig <hch@lst.de>
To: dsterba@suse.cz,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Christoph Hellwig <hch@lst.de>, 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 07:39:51 +0200 [thread overview]
Message-ID: <20190718053951.GA18122@lst.de> (raw)
In-Reply-To: <20190717153706.GJ20977@suse.cz>
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.
next prev parent reply other threads:[~2019-07-18 5:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-16 15:04 [PATCH v2 1/3] uuid: Add inline helpers to operate on raw buffers Andy Shevchenko
2019-07-16 15:04 ` [PATCH v2 2/3] Btrfs: Switch to use new generic UUID API Andy Shevchenko
2019-07-16 15:04 ` [PATCH v2 3/3] uuid: Remove no more needed macro Andy Shevchenko
2019-07-16 15:11 ` [PATCH v2 1/3] uuid: Add inline helpers to operate on raw buffers Christoph Hellwig
2019-07-16 15:22 ` Andy Shevchenko
2019-07-17 15:37 ` David Sterba
2019-07-17 15:53 ` Andy Shevchenko
2019-07-18 5:39 ` Christoph Hellwig [this message]
2019-07-18 17:52 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190718053951.GA18122@lst.de \
--to=hch@lst.de \
--cc=andriy.shevchenko@linux.intel.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=dsterba@suse.cz \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=lufq.fnst@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.