Re: [PATCH] public/io/blkif.h: make the comments on "sectors" self-consistent

[Anthony PERARD <anthony.perard@citrix.com>]

On Wed, Mar 20, 2019 at 12:52:28PM +0000, Paul Durrant wrote:
> Currently the comment at line #267 claims that the value should be
> expressed in number logical sectors, whereas the comment at line #613
> states that the value should be expressed strictly in units of 512 bytes.
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> ---
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Looking at xen-blkfront in Linux, I'm also not convinced that it would
> function correctly is sector-size != 512 anyway so I wonder whether this
> patch should go further and define that sector-size is strictly 512.
> ---
>  xen/include/public/io/blkif.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
> index 15a71e3fea..d7c904d9dc 100644
> --- a/xen/include/public/io/blkif.h
> +++ b/xen/include/public/io/blkif.h
> @@ -264,8 +264,7 @@
>   * sectors
>   *      Values:         <uint64_t>
>   *
> - *      The size of the backend device, expressed in units of its logical
> - *      sector size ("sector-size").
> + *      The size of the backend device, expressed in units of 512 bytes.
>   *
>   *****************************************************************************
>   *                            Frontend XenBus Nodes

But OVMF's frontend, minios' frontend, FreeBSD's frontend all do
sector-size * sectors to figure out the size of the media.
But looks like for at least OVMF, IO requests are handled with a sectors
size of 512.

I think FreeBSD's backend also set "sectors" based on "sector-size", but
on the other hand, "sector-size" is always set to 512.
I think it the same for the old qemu (before Paul's refactoring).

I think I would be fine with the patch going further and have
"sector-size" always 512, as some implementation are backed with
this assumption (Linux, which I haven't checked).

(I don't want to have to patch OVMF because the protocol changed.)

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel