Open qwandor opened 1 month ago
Shouldn't BLOCK_SIZE
be an associated constant?
Shouldn't
BLOCK_SIZE
be an associated constant?
I tried that but unfortunately it doesn't work, as Rust doesn't allow associated constants to be used in the types of trait methods. We can make it a trait parameter though.
In practice the crates I've checked so far both use 512 byte blocks. virtio-drivers uses 512 byte blocks for VirtIO block devices (as required by the VirtIO specification), embedded-sdmmc uses 512 blocks for SD cards and FAT32. Implementing block devices with other block sizes is less useful, as they won't be able to be used with filesystem drivers which expect 512 byte blocks. (On the other hand filesystems which work with larger blocks can be implemented just fine against a device which has 512 byte blocks, as they can just read or write multiple blocks at once if needed.)
Any further comments on this? Can it be merged?
I'm fine with just adding Block
in the first instance, which is a [u8; 512]
and then having the BlockDevice
trait not be generic over block size. The set of things that don't have 512 byte blocks (especially in an embedded context) is very small, and most of those will simply be a [u8; 4096]
, which we can add as a LargeBlock
or Block4K
.
Fixes #56.