qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: kwolf@redhat.com, dahi@linux.vnet.ibm.com,
	Public KVM Mailing List <qemu-devel@nongnu.org>,
	mihajlov@linux.vnet.ibm.com, borntraeger@de.ibm.com,
	stefanha@redhat.com, cornelia.huck@de.ibm.com,
	pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2 1/6] geometry: add bdrv functions for geometry and blocksize
Date: Thu, 27 Nov 2014 19:05:17 +0300	[thread overview]
Message-ID: <54774BBD.8020506@linux.vnet.ibm.com> (raw)
In-Reply-To: <87d288g0ap.fsf@blackfin.pond.sub.org>

On 11/27/2014 05:55 PM, Markus Armbruster wrote:
> I'm sorry for the delay.  I got the flu and have difficulties thinking
> straight for longer than a few minutes.
>
> Ekaterina Tumanova <tumanova@linux.vnet.ibm.com> writes:
>
>> Add driver functions for geometry and blocksize detection
>>
>> Signed-off-by: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com>
>> ---
>>   block.c                   | 26 ++++++++++++++++++++++++++
>>   include/block/block.h     | 20 ++++++++++++++++++++
>>   include/block/block_int.h |  3 +++
>>   3 files changed, 49 insertions(+)
>>
>> diff --git a/block.c b/block.c
>> index a612594..5df35cf 100644
>> --- a/block.c
>> +++ b/block.c
>> @@ -548,6 +548,32 @@ void bdrv_refresh_limits(BlockDriverState *bs, Error **errp)
>>       }
>>   }
>>
>> +struct ProbeBlockSize bdrv_probe_blocksizes(BlockDriverState *bs)
>> +{
>> +    BlockDriver *drv = bs->drv;
>> +    struct ProbeBlockSize err_geo = { .rc = -1 };
>> +
>> +    assert(drv != NULL);
>> +    if (drv->bdrv_probe_blocksizes) {
>> +        return drv->bdrv_probe_blocksizes(bs);
>> +    }
>> +
>> +    return err_geo;
>> +}
>
> I'm not sure about "probe".  Naming is hard.  "get"?
>
There was already "bdrv_get_geometry", and I wanted the _geometry and 
_blocksize functions to use the same naming convention.
I thought probe might be more suitable, since we do not "get" the value
for sure. maybe "detect"?

> Squashing status and actual payload into a single struct to use as
> return type isn't wrong, but unusual.  When the payload can't represent
> failure conveniently, we usually return status, and write the payload to
> a buffer provided by the caller, like this:
>
>      int bdrv_get_blocksizes(BlockDriverState *bs,
>                              uint16_t *physical_blk_sz,
>                              uint16_t *logical_blk_sz)
>
> Or, with a struct to hold both sizes:
>
>      int bdrv_get_blocksizes(BlockDriverState *bs, BlockSizes *bsz)
>
Do you insist on changing that? Returning a struct via stack seemed
useful to me, since there was less probability of caller allocating
a buffer of incorrect size or smth like that.

> Such a struct should ideally be used in other places where we store both
> sizes.
>
> A brief function contract comment wouldn't hurt.  Something like
>
>      /*
>       * Try to get @bs's logical and physical block size.
>       * Block sizes are always a multiple of BDRV_SECTOR_SIZE.
>       * On success, store them in ... and return 0.
>       * On failure, return -errno.
>       */
>
will do

>> +
>> +struct ProbeGeometry bdrv_probe_geometry(BlockDriverState *bs)
>> +{
>> +    BlockDriver *drv = bs->drv;
>> +    struct ProbeGeometry err_geo = { .rc = -1 };
>> +
>> +    assert(drv != NULL);
>> +    if (drv->bdrv_probe_geometry) {
>> +        return drv->bdrv_probe_geometry(bs);
>> +    }
>> +
>> +    return err_geo;
>> +}
>> +
>>   /*
>>    * Create a uniquely-named empty temporary file.
>>    * Return 0 upon success, otherwise a negative errno value.
>> diff --git a/include/block/block.h b/include/block/block.h
>> index 5450610..3287dbc 100644
>> --- a/include/block/block.h
>> +++ b/include/block/block.h
>> @@ -60,6 +60,24 @@ typedef enum {
>>       BDRV_REQ_MAY_UNMAP    = 0x4,
>>   } BdrvRequestFlags;
>>
>> +struct ProbeBlockSize {
>> +    int rc;
>> +    struct BlockSize {
>> +        uint16_t phys;
>> +        uint16_t log;
>> +    } size;
>> +};
>
> Use of uint16_t for block sizes is silly, but not your fault, you just
> follow existing usage.
>
>> +
>> +struct ProbeGeometry {
>> +    int rc;
>> +    struct HDGeometry {
>> +        uint32_t heads;
>> +        uint32_t sectors;
>> +        uint32_t cylinders;
>> +        uint32_t start;
>> +    } geo;
>> +};
>> +
>>   #define BDRV_O_RDWR        0x0002
>>   #define BDRV_O_SNAPSHOT    0x0008 /* open the file read only and save writes in a snapshot */
>>   #define BDRV_O_TEMPORARY   0x0010 /* delete the file after use */
>> @@ -538,6 +556,8 @@ AioContext *bdrv_get_aio_context(BlockDriverState *bs);
>>    * the old #AioContext is not executing.
>>    */
>>   void bdrv_set_aio_context(BlockDriverState *bs, AioContext *new_context);
>> +struct ProbeBlockSize bdrv_probe_blocksizes(BlockDriverState *bs);
>> +struct ProbeGeometry bdrv_probe_geometry(BlockDriverState *bs);
>>
>>   void bdrv_io_plug(BlockDriverState *bs);
>>   void bdrv_io_unplug(BlockDriverState *bs);
>> diff --git a/include/block/block_int.h b/include/block/block_int.h
>> index a1c17b9..830e564 100644
>> --- a/include/block/block_int.h
>> +++ b/include/block/block_int.h
>> @@ -271,6 +271,9 @@ struct BlockDriver {
>>       void (*bdrv_io_unplug)(BlockDriverState *bs);
>>       void (*bdrv_flush_io_queue)(BlockDriverState *bs);
>>
>> +    struct ProbeBlockSize (*bdrv_probe_blocksizes)(BlockDriverState *bs);
>> +    struct ProbeGeometry (*bdrv_probe_geometry)(BlockDriverState *bs);
>> +
>>       QLIST_ENTRY(BlockDriver) list;
>>   };
>
> Callbacks need contracts even more than functions do.  I know this file
> is full of bad examples.  Let's not add more :)
>

Thanks!
Kate.

  reply	other threads:[~2014-11-27 16:05 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-19 10:17 [Qemu-devel] [PATCH v2 0/6] Geometry and blocksize support for backing devices Ekaterina Tumanova
2014-11-19 10:17 ` [Qemu-devel] [PATCH v2 1/6] geometry: add bdrv functions for geometry and blocksize Ekaterina Tumanova
2014-11-21 10:01   ` Christian Borntraeger
2014-11-27 14:55   ` Markus Armbruster
2014-11-27 16:05     ` Ekaterina Tumanova [this message]
2014-11-28  8:25       ` Markus Armbruster
2014-11-19 10:17 ` [Qemu-devel] [PATCH v2 2/6] geometry: Detect blocksize via ioctls in separate static functions Ekaterina Tumanova
2014-11-21 10:17   ` Christian Borntraeger
2014-11-25 11:09     ` Stefan Hajnoczi
2014-11-27 17:41   ` Markus Armbruster
2014-11-28 10:58     ` Ekaterina Tumanova
2014-11-28 12:52       ` Markus Armbruster
2014-11-28 13:28         ` Ekaterina Tumanova
2014-11-19 10:17 ` [Qemu-devel] [PATCH v2 3/6] geometry: Add driver methods to probe blocksizes and geometry Ekaterina Tumanova
2014-11-21 13:52   ` Christian Borntraeger
2014-11-28  8:43   ` Markus Armbruster
2014-11-19 10:17 ` [Qemu-devel] [PATCH v2 4/6] geometry: Add block-backend wrappers for geometry probing Ekaterina Tumanova
2014-11-19 10:17 ` [Qemu-devel] [PATCH v2 5/6] geometry: Call backend function to detect geometry and blocksize Ekaterina Tumanova
2014-11-28 10:10   ` Markus Armbruster
2014-11-28 10:54     ` Ekaterina Tumanova
2014-11-28 12:58       ` Markus Armbruster
2014-11-28 10:27   ` Markus Armbruster
2014-11-19 10:17 ` [Qemu-devel] [PATCH v2 6/6] geometry: Target specific hook for s390x in geometry guessing Ekaterina Tumanova
2014-11-28 10:47   ` Markus Armbruster
2014-11-19 11:39 ` [Qemu-devel] [PATCH v2 0/6] Geometry and blocksize support for backing devices Christian Borntraeger
2014-11-19 14:01   ` [Qemu-devel] [PATCH] geometry: fix i386 compilation Ekaterina Tumanova
2014-11-19 14:40     ` Peter Maydell
2014-11-19 15:04       ` Cornelia Huck
2014-11-20 16:18         ` Kevin Wolf
2014-11-20 16:30           ` Christian Borntraeger
2014-11-21  9:42           ` Ekaterina Tumanova
2014-11-28 10:47     ` Markus Armbruster
2014-11-21 14:01 ` [Qemu-devel] [PATCH v2 0/6] Geometry and blocksize support for backing devices Christian Borntraeger
2014-11-25 13:01 ` Stefan Hajnoczi
2014-11-26 10:16   ` Ekaterina Tumanova
2014-11-28 10:35     ` Stefan Hajnoczi
2014-11-28 11:15       ` Ekaterina Tumanova
2014-11-28 13:40         ` Markus Armbruster
2014-11-28 10:40     ` Stefan Hajnoczi
2014-11-28 10:57     ` Markus Armbruster

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=54774BBD.8020506@linux.vnet.ibm.com \
    --to=tumanova@linux.vnet.ibm.com \
    --cc=armbru@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=dahi@linux.vnet.ibm.com \
    --cc=kwolf@redhat.com \
    --cc=mihajlov@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --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).