[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181017080854.GB24540@infradead.org>
Date: Wed, 17 Oct 2018 01:08:54 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Finn Thain <fthain@...egraphics.com.au>
Cc: Hannes Reinecke <hare@...e.de>,
"James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Michael Schmitz <schmitzmic@...il.com>,
linux-scsi@...r.kernel.org, linux-m68k@...ts.linux-m68k.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 5/6] esp_scsi: De-duplicate PIO routines
On Tue, Oct 16, 2018 at 10:52:26AM +1100, Finn Thain wrote:
> True enough. We agree that this #ifdef is undesirable. And yet when I
> tried it, I found an unexpected readability benefit to your suggestion:
>
> #ifdef CONFIG_SCSI_ESP_PIO
> u8 __iomem *fifo_reg;
> int send_cmd_error;
> u32 send_cmd_residual;
> #endif
>
> This grouping does help convey the purpose of these struct members, even
> though the #ifdef is meant for the compiler not for the human reader.
>
> So maybe it makes sense to group these definitions (they are all the same
> size):
>
> /* These are used by esp_scsi_send_pio_cmd() */
> u8 __iomem *fifo_reg;
> int send_cmd_error;
> u32 send_cmd_residual;
I like the grouping, and in fact the ifdef sounds fine to me as well.
> Do static checkers really complain about this? I think the validity of an
> extern can't be known until the final linkage is done.
None that I know of does, and as said before this patterns is very
common all over the kernel.
Powered by blists - more mailing lists