From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: dsterba@suse.cz, 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: Wed, 17 Jul 2019 18:53:52 +0300 [thread overview]
Message-ID: <20190717155352.GX9224@smile.fi.intel.com> (raw)
In-Reply-To: <20190717153706.GJ20977@suse.cz>
On Wed, Jul 17, 2019 at 05:37:06PM +0200, David Sterba wrote:
> On Tue, Jul 16, 2019 at 06:22:22PM +0300, Andy Shevchenko wrote:
> > On Tue, Jul 16, 2019 at 05:11:33PM +0200, Christoph Hellwig wrote:
> > > On Tue, Jul 16, 2019 at 06:04:16PM +0300, Andy Shevchenko wrote:
> > > I hate this raw naming. If people really want to use the generators on
> > > u8 fields a cast seems more descriptive then hiding it.
> >
> > 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.
>
> I tend to avoid the explicit typecasts for widely used functions because
> it's easy to forget them, and it overrides the type checks (that could
> be caught by compiler but also not).
>
> Specifically for uuid, the endianness might matter, so that we use the
> raw buffers makes things more explicit.
Thank you for the information.
Can you review v3 of the series where I attempted to satisfy everybody, Chris
in his wish to not do ugly raw generators and Btrfs by providing minimum needed
API helpers?
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2019-07-17 15:54 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 [this message]
2019-07-18 5:39 ` Christoph Hellwig
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=20190717155352.GX9224@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=dsterba@suse.cz \
--cc=hch@lst.de \
--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.