public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Metcalf <cmetcalf@tilera.com>
To: Boaz Harrosh <bharrosh@panasas.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>,
	<linux-nfs@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	Dean Hildebrand <dhildebz@umich.edu>
Subject: Re: [PATCH] nfs: fix a couple of minor portability issues
Date: Thu, 11 Aug 2011 09:26:34 -0400	[thread overview]
Message-ID: <4E43D88A.3060303@tilera.com> (raw)
In-Reply-To: <4E42FFDC.9090103@panasas.com>

On 8/10/2011 6:02 PM, Boaz Harrosh wrote:
> On 08/10/2011 10:56 AM, Chris Metcalf wrote:
>> Building on tilepro revealed two minor portability issues: the
>> blocklayout.c file used prefetchw() without #include <linux/prefetch.h>,
>> and the nfs4filelayout.c file used do_div() on an s64 not a u64.
>> This change fixes those two issues so the NFS code builds on tilepro.
>>
>> [...] 
>> diff --git a/fs/nfs/nfs4filelayout.c b/fs/nfs/nfs4filelayout.c
>> index e8915d4..6976a72 100644
>> --- a/fs/nfs/nfs4filelayout.c
>> +++ b/fs/nfs/nfs4filelayout.c
>> @@ -48,13 +48,13 @@ filelayout_get_dense_offset(struct nfs4_filelayout_segment *flseg,
>>  			    loff_t offset)
>>  {
>>  	u32 stripe_width = flseg->stripe_unit * flseg->dsaddr->stripe_count;
>> -	u64 tmp;
>> +	u64 tmp, uoff;
>>  
>>  	offset -= flseg->pattern_offset;
>> -	tmp = offset;
>> +	tmp = uoff = offset;
>>  	do_div(tmp, stripe_width);
>>  
>> -	return tmp * flseg->stripe_unit + do_div(offset, flseg->stripe_unit);
>> +	return tmp * flseg->stripe_unit + do_div(uoff, flseg->stripe_unit);
> For proper u64 divisions it is best to use the div_u64 (and div64_u64) and not
> use do_div. (And please don't add an unnecessary variable, just use a cast)

You can't use a cast with do_div() or you get errors about non-lvalues.

And the context here is that we want the remainder, not the divided result,
so we'd need a temporary variable anyway if we were going to use a routine
from math64.h, presumably div_u64_rem().  But that's just an inline wrapper
around do_div() anyway, so it's no more efficient, and not obviously any
less "cluttered" in the source code here.  The original code author (who
I'm adding belatedly to this email) may have a stronger opinion.

I'm not the author or maintainer of this code, I just want it to compile
without warning on 32-bit architectures :-)

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com


  reply	other threads:[~2011-08-11 13:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-10 17:56 [PATCH] nfs: fix a couple of minor portability issues Chris Metcalf
2011-08-10 22:02 ` Boaz Harrosh
2011-08-11 13:26   ` Chris Metcalf [this message]
2011-08-11 18:27     ` Boaz Harrosh
2011-08-11 19:32       ` [PATCH v2] nfs: fix a minor do_div portability issue Chris Metcalf
2011-08-11 20:54         ` [PATCH v3] " Boaz Harrosh
2011-08-11 15:17 ` [PATCH] nfs: fix a couple of minor portability issues Peng Tao

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=4E43D88A.3060303@tilera.com \
    --to=cmetcalf@tilera.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=bharrosh@panasas.com \
    --cc=dhildebz@umich.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    /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