[PATCH 00/15] blk: sandbox: Support binding a device with a given logical block size

[Bin Meng]

Hi Heinrich,

On Tue, Sep 26, 2023 at 4:58 PM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> On 9/26/23 10:43, Bin Meng wrote:
> > At present on Sandbox when binding to a host backing file, the host
> > block device is created with a hard-coded 512 bytes block size.
> >
> > Such assumption works for most cases, but for situation that with a raw
> > image file dump from a pre-formatted GPT partitioned disk image from a
> > 4KiB block size device, when binding this file to a host device and mapping
> > this device to a blkmap, "blkmap" command like "blkmap part" won't work
> > correctly, due to block size mismatch during parsing the partition table.
> >
> > This series updates Sandbox block driver, as well as the blkmap driver,
> > to get rid of the hard-coded 512 bytes block size assumption.
> >
> > This series is available at u-boot-x86/blk for testing.
>
> It is really good to have an easy way to test other block sizes.
>
> We can also use QEMU for alternative block sizes:
>
> $ qemu-system-riscv64 -device nvme,help
> logical_block_size=<size>
> physical_block_size=<size>

Yeah, please report any issue you find.

>
> In the commit messages, please, make it clear that you refer to logical
> block sizes and not to the physical block size.

For drivers we rarely care about physical_block_size as they always
operate on LBA. But I can write it down clearly that logical block
size is used.

Regards,
Bin