[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <77e08780-5f8b-5efd-d92d-c633f7b277a6@libero.it>
Date: Wed, 31 Jan 2018 23:23:55 +0100
From: Goffredo Baroncelli <kreijack@...ero.it>
To: Matthew Wilcox <willy@...radead.org>
Cc: Jeff Layton <jlayton@...nel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Goffredo Baroncelli <kreijack@...ind.it>
Subject: Re: [PATCH] Rename inode_cmp_iversion{+raw} to
inode_eq_iversion{+raw}
On 01/31/2018 10:55 PM, Matthew Wilcox wrote:
> On Wed, Jan 31, 2018 at 09:43:09PM +0100, Goffredo Baroncelli wrote:
>> The function inode_cmp_iversion{+raw} is counter-intuitive, because it
>> returns true when the counters are different and false when these are equal.
>>
>> Rename it to inode_eq_iversion{+raw}, which will returns true when
>> the counters are equal and false otherwise.
>
> A lot of places use !inode_eq_iversion(). I think we should have both
> inode_eq_iversion() and inode_ne_iversion().
A function is needed because before doing the comparing, a "conversion"
is needed.
My feeling is that the positive "form" is the more natural. And the notion
"!*eq*" is intuitive as the "*ne*".
>
> Also, we have 'inode' in the name, why keep the 'i'? inode_eq_version()
> and inode_ne_version() are shorter. We could even go so far as
> iversion_eq() and iversion_ne() if keeping 'iversion' in the string
> is important.
All the functions introduced by Jeff are in the form inode_<verb>_iversion.
So for consistency, inode_eq_iversion() makes sense.
>
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
Powered by blists - more mailing lists