[0/4] null_blk: fixes around nr_devices and log improvements

Message

André Almeida Sept. 13, 2019, 6:57 p.m. UTC

Hello,

This patch series address feedback for a previous patch series sent by
me "docs: block: null_blk: enhance document style"[1].

First patch removes a restriction that prevents null_blk to load with
(nr_devices == 0). This restriction breaks applications, so it's a bug. I
have tested it running the kernel with `null_blk.nr_devices=0`.

In the previous series I have changed the type of var nr_devices, but I
forgot to change the type at module_param(). The second patch fix that.

The third patch uses a cleaver approach to make log messages consistent
using pr_fmt and the last one add a note on how to do that at the
coding style documentation.

Thanks,
	André

[1] https://patchwork.kernel.org/project/linux-block/list/?series=172853

André Almeida (4):
  null_blk: do not fail the module load with zero devices
  null_blk: match the type of module parameter
  null_blk: format pr_* logs with pr_fmt
  coding-style: add explanation about pr_fmt macro

 Documentation/process/coding-style.rst | 10 +++++++++-
 drivers/block/null_blk.h               |  4 +++-
 drivers/block/null_blk_main.c          | 24 ++++++++++--------------
 drivers/block/null_blk_zoned.c         |  6 +++---
 4 files changed, 25 insertions(+), 19 deletions(-)

Comments

Jens Axboe Sept. 13, 2019, 7:03 p.m. UTC | #1

On Sep 13, 2019, at 11:58 AM, André Almeida <[e-mail]> wrote:
> 
> Hello,
> 
> This patch series address feedback for a previous patch series sent by
> me "docs: block: null_blk: enhance document style"[1].
> 
> First patch removes a restriction that prevents null_blk to load with
> (nr_devices == 0). This restriction breaks applications, so it's a bug. I
> have tested it running the kernel with `null_blk.nr_devices=0`.
> 
> In the previous series I have changed the type of var nr_devices, but I
> forgot to change the type at module_param(). The second patch fix that.
> 
> The third patch uses a cleaver approach to make log messages consistent
> using pr_fmt and the last one add a note on how to do that at the
> coding style documentation.

Please add Fixes tags to your patches.

André Almeida Sept. 13, 2019, 7:22 p.m. UTC | #2

On 9/13/19 4:03 PM, Jens Axboe wrote:
> On Sep 13, 2019, at 11:58 AM, André Almeida <[e-mail]> wrote:
>>
>> Hello,
>>
>> This patch series address feedback for a previous patch series sent by
>> me "docs: block: null_blk: enhance document style"[1].
>>
>> First patch removes a restriction that prevents null_blk to load with
>> (nr_devices == 0). This restriction breaks applications, so it's a bug. I
>> have tested it running the kernel with `null_blk.nr_devices=0`.
>>
>> In the previous series I have changed the type of var nr_devices, but I
>> forgot to change the type at module_param(). The second patch fix that.
>>
>> The third patch uses a cleaver approach to make log messages consistent
>> using pr_fmt and the last one add a note on how to do that at the
>> coding style documentation.
> 
> Please add Fixes tags to your patches. 
> 

I've added to [PATCH 1/4], should I add to all 4 patches?

Jens Axboe Sept. 13, 2019, 8:50 p.m. UTC | #3

On 9/13/19 1:22 PM, André Almeida wrote:
> On 9/13/19 4:03 PM, Jens Axboe wrote:
>> On Sep 13, 2019, at 11:58 AM, André Almeida <[e-mail]> wrote:
>>>
>>> Hello,
>>>
>>> This patch series address feedback for a previous patch series sent by
>>> me "docs: block: null_blk: enhance document style"[1].
>>>
>>> First patch removes a restriction that prevents null_blk to load with
>>> (nr_devices == 0). This restriction breaks applications, so it's a bug. I
>>> have tested it running the kernel with `null_blk.nr_devices=0`.
>>>
>>> In the previous series I have changed the type of var nr_devices, but I
>>> forgot to change the type at module_param(). The second patch fix that.
>>>
>>> The third patch uses a cleaver approach to make log messages consistent
>>> using pr_fmt and the last one add a note on how to do that at the
>>> coding style documentation.
>>
>> Please add Fixes tags to your patches.
>>
> 
> I've added to [PATCH 1/4], should I add to all 4 patches?

The ones where it's pertinent, yes, always. Both 1-2 fix issues with
the previous patches.