public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: 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 17:37:06 +0200	[thread overview]
Message-ID: <20190717153706.GJ20977@suse.cz> (raw)
In-Reply-To: <20190716152222.GJ9224@smile.fi.intel.com>

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:
> > > +static inline void guid_copy_from_raw(guid_t *dst, const __u8 *src)
> > > +{
> > > +	memcpy(dst, (const guid_t *)src, sizeof(guid_t));
> > > +}
> > > +
> > > +static inline void guid_copy_to_raw(__u8 *dst, const guid_t *src)
> > > +{
> > > +	memcpy((guid_t *)dst, src, sizeof(guid_t));
> > > +}
> > 
> > Maybe import_guid/export_guid is a better name?
> 
> Yes, sounds good to me.
> 
> > Either way, I don't think we need the casts, and they probably want
> > kerneldoc comments describing their use.
> > 
> > Same for the uuid side.
> 
> Got it.
> 
> > > +static inline void guid_gen_raw(__u8 *guid)
> > > +{
> > > +	guid_gen((guid_t *)guid);
> > > +}
> > > +
> > > +static inline void uuid_gen_raw(__u8 *uuid)
> > > +{
> > > +	uuid_gen((uuid_t *)uuid);
> > > +}
> > 
> > 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.

  reply	other threads:[~2019-07-17 15:37 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 [this message]
2019-07-17 15:53       ` Andy Shevchenko
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=20190717153706.GJ20977@suse.cz \
    --to=dsterba@suse.cz \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox