Re: block: remove unused header includes.
From: Randy Dunlap
Date: Sun Apr 26 2020 - 23:39:13 EST
On 4/26/20 8:35 PM, Ma, Jianpeng wrote:
>> -----Original Message-----
>> From: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
>> Sent: Monday, April 27, 2020 11:06 AM
>> To: Ma, Jianpeng <jianpeng.ma@xxxxxxxxx>; Christoph Hellwig
>> <hch@xxxxxxxxxxxxx>
>> Cc: axboe@xxxxxxxxx; Williams, Dan J <dan.j.williams@xxxxxxxxx>; linux-
>> kernel@xxxxxxxxxxxxxxx
>> Subject: Re: block: remove unused header includes.
>>
>> Hi,
>>
>> On 4/26/20 7:56 PM, Ma, Jianpeng wrote:
>>> This used deheader(git@xxxxxxxxxx:esr/deheader.git) to produce.
>>>
>>> Signed-off-by: Jianpeng Ma <jianpeng.ma@xxxxxxxxx>
>>> ---
>>> block/badblocks.c | 6 ------
>>> block/bfq-cgroup.c | 10 ----------
>>> block/bfq-iosched.c | 13 -------------
>>> block/bio-integrity.c | 6 ------
>>> block/bio.c | 14 --------------
>>> block/blk-cgroup.c | 10 ----------
>>> block/blk-core.c | 24 ------------------------
>>> block/blk-exec.c | 5 -----
>>> block/blk-flush.c | 10 ----------
>>> block/blk-integrity.c | 6 ------
>>> block/blk-ioc.c | 7 -------
>>> block/blk-lib.c | 5 -----
>>> block/blk-map.c | 4 ----
>>> block/blk-merge.c | 5 -----
>>> block/blk-mq-cpumap.c | 8 --------
>>> block/blk-mq-debugfs.c | 6 ------
>>> block/blk-mq-pci.c | 4 ----
>>> block/blk-mq-rdma.c | 1 -
>>> block/blk-mq-sched.c | 7 -------
>>> block/blk-mq-sysfs.c | 15 +--------------
>>> block/blk-mq-tag.c | 5 -----
>>> block/blk-mq-virtio.c | 4 ----
>>> block/blk-mq.c | 22 ----------------------
>>> block/blk-pm.c | 4 ----
>>> block/blk-settings.c | 8 --------
>>> block/blk-softirq.c | 6 ------
>>> block/blk-stat.c | 5 -----
>>> block/blk-sysfs.c | 9 ---------
>>> block/blk-throttle.c | 5 -----
>>> block/blk-timeout.c | 5 -----
>>> block/blk-wbt.c | 6 ------
>>> block/blk-zoned.c | 7 -------
>>> block/bounce.c | 15 ---------------
>>> block/bsg-lib.c | 5 -----
>>> block/bsg.c | 11 -----------
>>> block/cmdline-parser.c | 1 -
>>> block/elevator.c | 15 ---------------
>>> block/genhd.c | 14 --------------
>>> block/ioctl.c | 8 --------
>>> block/ioprio.c | 11 -----------
>>> block/kyber-iosched.c | 9 ---------
>>> block/mq-deadline.c | 14 --------------
>>> block/partitions/amiga.c | 1 -
>>> block/partitions/core.c | 4 ----
>>> block/partitions/efi.c | 3 ---
>>> block/partitions/karma.c | 1 -
>>> block/partitions/ldm.c | 4 ----
>>> block/partitions/mac.c | 1 -
>>> block/scsi_ioctl.c | 14 --------------
>>> block/sed-opal.c | 9 ---------
>>> block/t10-pi.c | 1 -
>>> fs/block_dev.c | 16 ----------------
>>> 52 files changed, 1 insertion(+), 408 deletions(-)
>>>
>>> diff --git a/block/badblocks.c b/block/badblocks.c index
>>> 2e5f5697db35..4e4eb0fc9eb9 100644
>>> --- a/block/badblocks.c
>>> +++ b/block/badblocks.c
>>> @@ -8,12 +8,6 @@
>>> */
>>>
>>> #include <linux/badblocks.h>
>>> -#include <linux/seqlock.h>
>>
>> above is used by:
>> seq = read_seqbegin(&bb->lock);
>>
>>> -#include <linux/device.h>
>>
>> struct device is used in this source file.
>>
>>> -#include <linux/kernel.h>
>>> -#include <linux/module.h>
>>> -#include <linux/stddef.h>
>>
>> NULL is used in this source file.
>>
>>> -#include <linux/types.h>
>>
>> sector_t is used in this source file.
>>
>>> #include <linux/slab.h>
>>>
>>> /**
>>
>>
>>
>> Can you explain the criteria that 'deheader' use to decide that a header file can
>> be removed?
>>
> Deheader iterator remove the #include and do make. If no fail mean this #include can remove.
In some cases it just means that headerfile-a sucks in headerfile-b automagically,
but that's not what we want to see, according to rule #1.
We want all needed header files to be explicitly #included.
>
>> And are you aware of rule #1 in Documentation/process/submit-checklist.rst:
>>
>> 1) If you use a facility then #include the file that defines/declares
>> that facility. Don't depend on other header files pulling in ones
>> that you use.
>>
> Is this rule mean for #ifdef case?
It depends. We try not to do things like
#ifdef CONFIG_OPTIONA
#include <linux/optiona.h>
#endif
and instead just do
#include <linux/optiona.h>
but that's probably not a universal rule.
--
~Randy