All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Vivier <Laurent.Vivier@bull.net>
To: "Jose R. Santos" <jrs@us.ibm.com>
Cc: Dave Kleikamp <shaggy@linux.vnet.ibm.com>,
	cmm@us.ibm.com, Andreas Dilger <adilger@clusterfs.com>,
	linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [RFC][PATCH] Set JBD2_FEATURE_INCOMPAT_64BIT on filesystems larger than 32-bit blocks (take 2).
Date: Tue, 05 Jun 2007 18:07:30 +0200	[thread overview]
Message-ID: <46658A42.7040105@bull.net> (raw)
In-Reply-To: <20070605104657.13d60531@gara>

[-- Attachment #1: Type: text/plain, Size: 1677 bytes --]

Jose R. Santos wrote:
> On Tue, 05 Jun 2007 16:03:44 +0200
> Laurent Vivier <Laurent.Vivier@bull.net> wrote:
>> Jose R. Santos wrote:
>>> Hi Laurent,
>>>
>>> In this particular case though, the value of s_blocks_count_hi should not be
>>> uses on its own.  The correct way would be to use ext4_blocks_count() which
>>> already does the endian conversion.  If you think the code could confuse
>>> people as to how to access the data in s_blocks_count_hi, wouldn't hiding it
>>> through the use of a macro make more sense than doing an unnecessary endian
>>> conversion?
>>>
>> Yes, I think the code could confuse people, but I don't think defining "Yet
>> Another Macro" is a good choice (IMHO).
>>
>> I think we can resolve this (non-)issue by two ways:
>> - using le32_to_cpu() (but I agree it does an unnecessary endian conversion on
>> big-endian systems)
> 
> I just think that adding extra instructions for the sake of slightly
> better code readability is wrong, especially when the value
> s_blocks_count_hi should not be used on its own.
> 
>> - put a comment on the line (but are we allowed to put comments in kernel source
>> code... ;-) )
> 
> One advantage of a macro here is that we would make the code more
> explicit and should be able to eliminate the need for those 4 lines of
> comments that this patch adds.

IMHO, you should do as _you_ think it is better... but as Mingming did the first
comment perhaps she can explain what she thought.

Regards,
Laurent
-- 
------------- Laurent.Vivier@bull.net  --------------
       "Any sufficiently advanced technology is
  indistinguishable from magic." - Arthur C. Clarke


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-06-05 16:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-01 15:52 [RFC][PATCH] Set JBD2_FEATURE_INCOMPAT_64BIT on filesystems larger than 32-bit blocks Jose R. Santos
2007-06-01 22:54 ` Andreas Dilger
2007-06-04 16:32   ` [RFC][PATCH] Set JBD2_FEATURE_INCOMPAT_64BIT on filesystems larger than 32-bit blocks (take 2) Jose R. Santos
2007-06-04 17:57     ` Andreas Dilger
2007-06-04 23:01       ` Mingming Cao
2007-06-04 23:32         ` Andreas Dilger
2007-06-05 11:41         ` Jose R. Santos
2007-06-05 13:14           ` Dave Kleikamp
2007-06-05 13:26             ` Laurent Vivier
2007-06-05 13:49               ` Jose R. Santos
2007-06-05 14:03                 ` Laurent Vivier
2007-06-05 15:46                   ` Jose R. Santos
2007-06-05 16:07                     ` Laurent Vivier [this message]
2007-06-05 17:46                       ` Mingming Cao
2007-06-05 19:58                         ` Jose R. Santos

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=46658A42.7040105@bull.net \
    --to=laurent.vivier@bull.net \
    --cc=adilger@clusterfs.com \
    --cc=cmm@us.ibm.com \
    --cc=jrs@us.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=shaggy@linux.vnet.ibm.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.