Re: [PATCH 5/7] btrfs-progs: backref: add list_first_pref helper

From: Jeff Mahoney <jeffm@suse.com>
To: Nikolay Borisov <nborisov@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 5/7] btrfs-progs: backref: add list_first_pref helper
Date: Wed, 26 Jul 2017 09:25:24 -0400	[thread overview]
Message-ID: <90a21da3-6c0f-50cc-a95f-d05ed1a9f05e@suse.com> (raw)
In-Reply-To: <bf9d2dae-4291-2dad-9101-f5fb18215699@suse.com>

[-- Attachment #1.1: Type: text/plain, Size: 1293 bytes --]

On 7/26/17 9:22 AM, Jeff Mahoney wrote:
> On 7/26/17 3:08 AM, Nikolay Borisov wrote:
>>
>>
>> On 25.07.2017 23:51, jeffm@suse.com wrote:
>>> From: Jeff Mahoney <jeffm@suse.com>
>>>
>>> ---
>>>  backref.c | 11 +++++++----
>>>  1 file changed, 7 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/backref.c b/backref.c
>>> index ac1b506..be3376a 100644
>>> --- a/backref.c
>>> +++ b/backref.c
>>> @@ -130,6 +130,11 @@ struct __prelim_ref {
>>>  	u64 wanted_disk_byte;
>>>  };
>>>  
>>> +static struct __prelim_ref *list_first_pref(struct list_head *head)
>>> +{
>>> +	return list_first_entry(head, struct __prelim_ref, list);
>>> +}
>>> +
>>
>> I think this just adds one more level of abstraction with no real
>> benefit whatsoever. Why not drop the patch entirely.
> 
> Ack.  I thought it might be more readable but it ends up taking the same
> number of characters.

Actually, no, it doesn't.  That's only true if using 'head' as the list head
as in the helper.

It ends up being

	ref = list_first_pref(&prefstate->pending_missing_keys);
vs
	ref = list_first_entry(&prefstate->pending_missing_keys,
                               struct __prelim_ref, list);

and I have to say I prefer reading the former.

-Jeff

-- 
Jeff Mahoney
SUSE Labs

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