qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
To: Stefan Hajnoczi <stefanha@redhat.com>, Sam Li <faithilikerun@gmail.com>
Cc: qemu-devel@nongnu.org, hare@suse.de,
	Hanna Reitz <hreitz@redhat.com>,
	dmitry.fomichev@wdc.com, Kevin Wolf <kwolf@redhat.com>,
	Fam Zheng <fam@euphon.net>,
	qemu-block@nongnu.org
Subject: Re: [RFC v3 2/5] qemu-io: add zoned block device operations.
Date: Tue, 28 Jun 2022 18:11:39 +0900	[thread overview]
Message-ID: <d6f0ca3e-2463-5a42-f284-c54b4877cf15@opensource.wdc.com> (raw)
In-Reply-To: <Yrq0QwRahF9wJh1S@stefanha-x1.localdomain>

On 6/28/22 16:56, Stefan Hajnoczi wrote:
> On Mon, Jun 27, 2022 at 08:19:14AM +0800, Sam Li wrote:
>> diff --git a/qemu-io-cmds.c b/qemu-io-cmds.c
>> index 2f0d8ac25a..3f2592b9f5 100644
>> --- a/qemu-io-cmds.c
>> +++ b/qemu-io-cmds.c
>> @@ -1706,6 +1706,122 @@ static const cmdinfo_t flush_cmd = {
>>      .oneline    = "flush all in-core file state to disk",
>>  };
>>  
>> +static int zone_report_f(BlockBackend *blk, int argc, char **argv)
>> +{
>> +    int ret;
>> +    int64_t offset, len, nr_zones;
>> +    int i = 0;
>> +
>> +    ++optind;
>> +    offset = cvtnum(argv[optind]);
>> +    ++optind;
>> +    len = cvtnum(argv[optind]);
>> +    ++optind;
>> +    nr_zones = cvtnum(argv[optind]);
>> +
>> +    g_autofree BlockZoneDescriptor *zones = g_new(BlockZoneDescriptor, nr_zones);
>> +    ret = blk_zone_report(blk, offset, len, &nr_zones, zones);
>> +    while (i < nr_zones) {
> 
> Does blk_zone_report() set nr_zones to 0 on failure or do we need to
> check if (ret < 0) here?

ret = 0 means "no zone reported" which happen only if nr_zones is 0 or the
start offset is past the end of the disk capacity. ret < 0 would mean that
a report zone operation was actually attempted and failed (EIO, ENOMEM etc).

> 
>> +        fprintf(stdout, "start: 0x%lx, len 0x%lx, cap 0x%lx, wptr 0x%lx, "
> 
> The rest of the source file uses printf() instead of fprintf(stdout,
> ...). That's usually preferred because it's shorter.
> 
>> +                        "zcond:%u, [type: %u]\n",
> 
> Please use PRIx64 instead of lx format specifiers for portability. On
> 32-bit hosts lx is 32-bit, not 64-bit. You can grep QEMU's code for
> examples of PRIx64.
> 
>> +                zones[i].start, zones[i].length, zones[i].cap, zones[i].wp,
>> +                zones[i].cond, zones[i].type);
>> +        ++i;
>> +    }
> 
> A for loop is more idiomatic:
> 
>   for (int i = 0; i < nr_zones; i++) {
>       ...
>   }
> 
>> +    return ret;
>> +}
>> +
>> +static const cmdinfo_t zone_report_cmd = {
>> +        .name = "zone_report",
>> +        .altname = "f",
>> +        .cfunc = zone_report_f,
>> +        .argmin = 3,
>> +        .argmax = 3,
>> +        .args = "offset [offset..] len [len..] number [num..]",
> 
> The arguments are "offset len number". This command does not accept
> optional offset/len/num arguments.

The arguments should be offset + len OR offset + number of zones. Having
the 3 of them does not make sense to me. The interface would then be:

(1) offset + len -> report all zones in the block range [offset .. offset
+ len - 1]

(2) offset + number of zones -> report at most "number of zones" from the
zone containing the block at "offset".

(2) matches the semantic used at the device command level. So I prefer to
approach (1).

> 
>> +        .oneline = "report a number of zones",
> 
> Maybe "report zone information".
> 
>> +};
>> +
>> +static int zone_open_f(BlockBackend *blk, int argc, char **argv)
>> +{
>> +    int64_t offset, len;
>> +    ++optind;
>> +    offset = cvtnum(argv[optind]);
>> +    ++optind;
>> +    len = cvtnum(argv[optind]);
>> +    return blk_zone_mgmt(blk, zone_open, offset, len);
> 
> Where is the error reported? When I look at read_f() I see:
> 
>     if (ret < 0) {
>         printf("read failed: %s\n", strerror(-ret));
> 
> I think something similar is needed because qemu-io.c does not print an
> error message for us. The same is true for the other commands defined in
> this patch.
> 
>> +}
>> +
>> +static const cmdinfo_t zone_open_cmd = {
>> +        .name = "zone_open",
>> +        .altname = "f",
>> +        .cfunc = zone_open_f,
>> +        .argmin = 2,
>> +        .argmax = 2,
>> +        .args = "offset [offset..] len [len..]",
> 
> There are no optional offset/len args. The same is true for the other
> commands below.


-- 
Damien Le Moal
Western Digital Research


  parent reply	other threads:[~2022-06-28  9:29 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-27  0:19 [RFC v3 0/5] *** Add support for zoned device *** Sam Li
2022-06-27  0:19 ` [RFC v3 1/5] block: add block layer APIs resembling Linux ZonedBlockDevice ioctls Sam Li
2022-06-27  7:21   ` Hannes Reinecke
2022-06-27  7:45     ` Sam Li
2022-06-27 14:15   ` Stefan Hajnoczi
2022-06-28  8:05     ` Sam Li
2022-06-28  9:05       ` Damien Le Moal
2022-06-28 10:23         ` Sam Li
2022-06-29  1:43           ` Damien Le Moal
2022-06-29  1:50             ` Sam Li
2022-06-29  2:32               ` Damien Le Moal
2022-06-29  2:35                 ` Sam Li
2022-06-27  0:19 ` [RFC v3 2/5] qemu-io: add zoned block device operations Sam Li
2022-06-27  7:30   ` Hannes Reinecke
2022-06-27  8:31     ` Sam Li
2022-06-28  7:56   ` Stefan Hajnoczi
2022-06-28  9:02     ` Sam Li
2022-06-28  9:11     ` Damien Le Moal [this message]
2022-06-28 10:27       ` Sam Li
2022-06-27  0:19 ` [RFC v3 3/5] file-posix: introduce get_sysfs_long_val for zoned device information Sam Li
2022-06-27  7:31   ` Hannes Reinecke
2022-06-27  8:32     ` Sam Li
2022-06-28  8:09   ` Stefan Hajnoczi
2022-06-28  9:18     ` Sam Li
2022-06-27  0:19 ` [RFC v3 4/5] file-posix: introduce get_sysfs_str_val for device zoned model Sam Li
2022-06-27  7:41   ` Hannes Reinecke
2022-06-27  8:44     ` Sam Li
2022-06-27  0:19 ` [RFC v3 5/5] qemu-iotests: add zone operation tests Sam Li
2022-06-27  7:42   ` Hannes Reinecke
2022-06-28  8:19   ` Stefan Hajnoczi
2022-06-28  9:34     ` Sam Li
2022-06-30 10:11       ` Stefan Hajnoczi

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=d6f0ca3e-2463-5a42-f284-c54b4877cf15@opensource.wdc.com \
    --to=damien.lemoal@opensource.wdc.com \
    --cc=dmitry.fomichev@wdc.com \
    --cc=faithilikerun@gmail.com \
    --cc=fam@euphon.net \
    --cc=hare@suse.de \
    --cc=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).