All of lore.kernel.org
 help / color / mirror / Atom feed
From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
To: Niklas Cassel <Niklas.Cassel@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 16:35:41 +0900	[thread overview]
Message-ID: <aae7748c-7915-28b4-75a4-033dc76f75d2@opensource.wdc.com> (raw)
In-Reply-To: <YaIBOPmCC6QH2rei@x1-carbon>

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.

> Similarly, nvme_zone_parse_entry() takes a ZNS zone representation, stored in a
> struct nvme_zone_descriptor *entry, and to convert it to a struct blk_zone.
> 
> 
> When comparing against struct members inside entry, the NVMe enums have to be
> used, i.e. NVME_ZONE_TYPE_SEQWRITE_REQ.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/nvme/host/zns.c#n158
> 
> However, assigning, or comparing against struct members of struct blk_zone,
> the blk layer enums have to be used, i.e. BLK_ZONE_TYPE_SEQWRITE_REQ:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/nvme/host/zns.c#n164
> 
> And why did you give me your Reviewed-by on the NVMe patch that uses the
> blk later enums here:
> https://lore.kernel.org/linux-nvme/ef1c39ab-7b56-6a37-0f4f-1ca111d5b48b@opensource.wdc.com/T/#t
> 
> Be consistent, either ack both or nack both :)

I am not nacking anything. I am giving my opinion, which is that I find this
code change useless.

>> A more sensible patch may be to add a static checking that all BLK_ZONE_COND_*
>> and BLK_ZONE_TYPE_* enum values are equal to the ZBC defined values in
>> include/scsi/scsi_proto.h (ZBC_ZONE_COND_* and ZBC_ZONE_TYPE_* macros).
> 
> The blk-zoned block layer is obviously modeled after ZBC, that is why all the
> enum constants happen to be the same. But this obviously doesn't have to be
> true for all existing/future lower level interfaces which supports zones.

If you are worried that sd_zbc_parse_report() does not fill the values as
defined for struct blk_zone, then add something like:

static_assert(BLK_ZONE_COND_FULL == ZBC_ZONE_COND_FULL);
static_assert(BLK_ZONE_TYPE_CONVENTIONAL == ZBC_ZONE_TYPE_CONV);

at the beginning of that function.

blk_dev_revalidate_zones() will check everything is valid anyway.

-- 
Damien Le Moal
Western Digital Research

  reply	other threads:[~2021-11-29  7:37 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 [this message]
2021-11-29 13:15       ` Niklas Cassel

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=aae7748c-7915-28b4-75a4-033dc76f75d2@opensource.wdc.com \
    --to=damien.lemoal@opensource.wdc.com \
    --cc=Niklas.Cassel@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.