On Sun, Oct 6, 2024 at 4:36 AM Max Gurtovoy <mgurtovoy@xxxxxxxxxx> wrote: > > > On 03/10/2024 2:56, Daniel Verkamp wrote: > > On Mon, Sep 30, 2024 at 6:45 PM Daniel Verkamp <dverkamp@xxxxxxxxxxxx> wrote: > >> On Wed, Sep 25, 2024 at 4:42 PM Max Gurtovoy <mgurtovoy@xxxxxxxxxx> wrote: > > [...] > >>> I'm curious if you've encountered any actual implementations where > >>> drivers send non-block-size-aligned requests to block devices. I never > >>> saw such implementation. > >> I don't know of any real-world implementations like this, but the > >> point of the spec is to allow interoperability without having to know > >> about every implementation. > > I did find at least one existing real-world driver implementation that > > ignores blk_size and VIRTIO_BLK_F_BLK_SIZE - the u-boot virtio-blk > > driver: https://github.com/u-boot/u-boot/blob/master/drivers/virtio/virtio_blk.c > > > > So this is not just spec language lawyering; this driver depends on > > the ability to read/write at arbitrary 512-byte sector addresses and > > data sizes, and it seems like it should be allowed to do that based on > > my reading of the spec. > > > > (Perhaps u-boot's driver does not work with the QEMU's virtio-blk > > device with certain storage configurations, per Stefan's note, but > > that is again just one device implementation.) > > Vague specifications and inconsistent interpretations should be avoided. > > I'm trying to make the situation better. Thanks, I do want to improve the situation as well, and hopefully we can reach that while keeping compatibility. > I'll send a V2 according to the comments. > > BTW, Are you familiar with some virtio-blk device that implements the > buffer-cache logic you've described ? or is it only a theoretical > discussion ? The most straightforward (software) implementation of a virtio-blk device on a Linux host system would be a raw disk image stored as a regular file on a filesystem, opened in the normal (non-O_DIRECT) way, with the device implementation translating VIRTIO_BLK_T_IN/OUT requests into [p]read/write syscalls; arguably, the host operating system's fs/mm code would be handling the buffering in this case, so it's not really part of the block device implementation per se, but I would still count it.
