[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <92334639-9d34-5e6a-2c43-945a20077394@kernel.dk>
Date: Sat, 1 Dec 2018 11:38:48 -0700
From: Jens Axboe <axboe@...nel.dk>
To: Frank Lee <tiny.windzz@...il.com>
Cc: ed.cashin@....org, philipp.reisner@...bit.com,
Lars Ellenberg <lars.ellenberg@...bit.com>,
Josef Bacik <josef@...icpanda.com>,
linux-block@...r.kernel.org, josh.h.morris@...ibm.com,
pjk1939@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
drbd-dev@...ts.linbit.com, nbd@...er.debian.org
Subject: Re: [PATCH v2] block: Change to use DEFINE_SHOW_ATTRIBUTE macro
On 12/1/18 11:31 AM, Frank Lee wrote:
> On Sun, Dec 2, 2018 at 2:11 AM Jens Axboe <axboe@...nel.dk> wrote:
>>
>> On 12/1/18 7:24 AM, Yangtao Li wrote:
>>> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>>>
>>> Signed-off-by: Yangtao Li <tiny.windzz@...il.com>
>>> ---
>>> changes in v2:
>>> -Modify some function names to avoid compilation errors
>>
>> The fact that your previous patch didn't even compile doesn't fill me
>> with a lot of confidence in the amount of diligence and testing
>> you apply to your patches.
>>
>> Why would you send something out that you didn't even compile?
>>
>> --
>> Jens Axboe
>>
> These changes are the same and only require a small change.
> Most of the changes are fine, so it's a bit negligent.
When someone is sending a patch for inclusion, at the very minimum
I expect it to have been compiled, and preferably tested too. Doesn't
matter how small the change is, even a one-liner should go through that.
That said, I'm not a huge fan of changes like this. It completely
hides what is going on for someone reading the code, and it's not
like there's a win on code size for example. The only win seems to
be that driver writes can't mess it up, which is a nice benefit.
--
Jens Axboe
Powered by blists - more mailing lists