All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <Niklas.Cassel@wdc.com>
To: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH 1/2] scsi: sd_zbc: Compare against block layer enum values
Date: Mon, 29 Nov 2021 13:15:26 +0000	[thread overview]
Message-ID: <YaTSbcs/cNfl/hKO@x1-carbon> (raw)
In-Reply-To: <aae7748c-7915-28b4-75a4-033dc76f75d2@opensource.wdc.com>

On Mon, Nov 29, 2021 at 04:35:41PM +0900, Damien Le Moal wrote:
> On 2021/11/27 18:58, Niklas Cassel wrote:
> > On Sat, Nov 27, 2021 at 10:00:57AM +0900, Damien Le Moal wrote:
> >> On 2021/11/26 21:55, Niklas Cassel wrote:
> >>> From: Niklas Cassel <niklas.cassel@wdc.com>
> >>>
> >>> sd_zbc_parse_report() fills in a struct blk_zone, which is the block layer
> >>> representation of a zone. This struct is also what will be copied to user
> >>> for a BLKREPORTZONE ioctl.
> >>>
> >>> Since sd_zbc_parse_report() compares against zone.type and zone.cond, which
> >>> are members of a struct blk_zone, the correct enum values to compare
> >>> against are the enum values defined by the block layer.
> >>>
> >>> These specific enum values for ZBC and the block layer happen to have the
> >>> same enum constants, but they could theoretically have been different.
> >>>
> >>> Compare against the block layer enum values, to make it more obvious that
> >>> struct blk_zone is the block layer representation of a zone, and not the
> >>> SCSI/ZBC representation of a zone.
> >>>
> >>> Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
> >>> ---
> >>>  drivers/scsi/sd_zbc.c | 4 ++--
> >>>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/scsi/sd_zbc.c b/drivers/scsi/sd_zbc.c
> >>> index ed06798983f8..024f1bec6e5a 100644
> >>> --- a/drivers/scsi/sd_zbc.c
> >>> +++ b/drivers/scsi/sd_zbc.c
> >>> @@ -62,8 +62,8 @@ static int sd_zbc_parse_report(struct scsi_disk *sdkp, u8 *buf,
> >>>  	zone.capacity = zone.len;
> >>>  	zone.start = logical_to_sectors(sdp, get_unaligned_be64(&buf[16]));
> >>>  	zone.wp = logical_to_sectors(sdp, get_unaligned_be64(&buf[24]));
> >>> -	if (zone.type != ZBC_ZONE_TYPE_CONV &&
> >>> -	    zone.cond == ZBC_ZONE_COND_FULL)
> >>> +	if (zone.type != BLK_ZONE_TYPE_CONVENTIONAL &&
> >>> +	    zone.cond == BLK_ZONE_COND_FULL)
> >>>  		zone.wp = zone.start + zone.len;
> >>
> >> For the sake of avoiding layering violation, I would keep the code as is, unles
> >> Martin and James are OK with this ?
> > 
> > Sorry, but I don't understand this comment.
> > 
> > The whole point of sd_zbc_parse_report() is to take a ZBC zone representation,
> > stored in u8 *buf, and to convert it to a struct blk_zone used by the block
> > layer.
> 
> Yes. So what is the problem with using the scsi_proto.h defined ZBC_ZONE_*
> macros ? We are deep in scsi territory with this code, so using an UAPI defined
> macro is weird.

There is no problem with the existing code.
I simply think that it is strictly more correct and slightly less confusing
to use the BLK_ZONE_ enums when accessing members of struct blk_zone.

I didn't see the weirdness of doing so, especially considering that NVMe
uses the BLK_ZONE_ enums when assigning members of struct blk_zone, and
since struct blk_zone, which is the type we are using here, is itself
defined in (and only in) the UAPI header include/uapi/linux/blkzoned.h.

Anyway, I will drop this patch from the series and send out a V2 of patch 2/2.


Kind regards,
Niklas

      reply	other threads:[~2021-11-29 13:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-26 12:55 [PATCH 1/2] scsi: sd_zbc: Compare against block layer enum values Niklas Cassel
2021-11-26 12:56 ` [PATCH 2/2] scsi: sd_zbc: Clean up sd_zbc_parse_report() setting of wp Niklas Cassel
2021-11-26 14:10   ` Johannes Thumshirn
2021-11-27  1:03   ` Damien Le Moal
2021-11-26 14:09 ` [PATCH 1/2] scsi: sd_zbc: Compare against block layer enum values Johannes Thumshirn
2021-11-27  1:00 ` Damien Le Moal
2021-11-27  9:58   ` Niklas Cassel
2021-11-29  7:35     ` Damien Le Moal
2021-11-29 13:15       ` Niklas Cassel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YaTSbcs/cNfl/hKO@x1-carbon \
    --to=niklas.cassel@wdc.com \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=jejb@linux.ibm.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.