Re: [Qemu-devel] [PATCH v3 3/5] block: Add driver methods to probe blocksizes and geometry

[Thomas Huth]

On Thu, 11 Dec 2014 14:17:21 +0300
Ekaterina Tumanova <address@hidden> wrote:

> On 12/10/2014 04:14 PM, Thomas Huth wrote:
> > On Fri,  5 Dec 2014 18:56:19 +0100
> > Ekaterina Tumanova <address@hidden> wrote:
...
> >> diff --git a/block/raw_bsd.c b/block/raw_bsd.c
> >> index 401b967..cfd5249 100644
> >> --- a/block/raw_bsd.c
> >> +++ b/block/raw_bsd.c
> >> @@ -173,6 +173,18 @@ static int raw_probe(const uint8_t *buf, int 
> >> buf_size, const char *filename)
> >>       return 1;
> >>   }
> >>
> >> +static int raw_probe_blocksizes(BlockDriverState *bs, BlockSizes *bsz)
> >> +{
> >> +    bdrv_probe_blocksizes(bs->file, bsz);
> >> +
> >> +    return 0;
> >> +}
> >> +
> >> +static int raw_probe_geometry(BlockDriverState *bs, hdGeometry *geo)
> >> +{
> >> +    return bdrv_probe_geometry(bs->file, geo);
> >> +}
> >> +
> >>   static BlockDriver bdrv_raw = {
> >>       .format_name          = "raw",
> >>       .bdrv_probe           = &raw_probe,
> >> @@ -190,6 +202,8 @@ static BlockDriver bdrv_raw = {
> >>       .has_variable_length  = true,
> >>       .bdrv_get_info        = &raw_get_info,
> >>       .bdrv_refresh_limits  = &raw_refresh_limits,
> >> +    .bdrv_probe_blocksizes = &raw_probe_blocksizes,
> >> +    .bdrv_probe_geometry  = &raw_probe_geometry,
> >>       .bdrv_is_inserted     = &raw_is_inserted,
> >>       .bdrv_media_changed   = &raw_media_changed,
> >>       .bdrv_eject           = &raw_eject,
> >
> > Hmmm, raw_probe_blocksizes() calls bdrv_probe_blocksizes(), but when I
> > look at your patch 1/5, bdrv_probe_blocksizes() wants to call
> > drv->bdrv_probe_blocksizes() (i.e. raw_probe_blocksizes()) again?
> > Don't you get an endless recursive loop here? Or did I miss something?
> > *confused*
> >
> >   Thomas
> 
> No I don't :) Because raw_probe_blocksizes indeed calls 
> bdrv_probe_blocksizes() dispatcher, but it calls it against different
> driver: "bs->file". This child points to other driver, which represents
> the actual nature of the device.
> 
> So the 2nd drv->bdrv_probe_blocksizes() call will actually be
> a call to either hdev_probe_blocksizes() for "host_device" driver or
> will be null for other drivers.

Ah, ok, you're right of course! Thanks for the explanation and sorry
for the confusion!

 Thomas