Split crate to two

[no111u3]

This crate are great but it consist two functionalities: fat file system interface and implementation and sd/mcc card high level driver. I think we need to split this crate to two - one for fat fs and one for sd card abstraction. Thanks.

[thejpster]

This crate is intended to allow you to read/write files on a FAT formatted SD card on your Rust Embedded device, as easily as using the SdFat Arduino library.

Can you list the advantages that splitting the crate would bring? As stated in the README, the primary goal is simplicity.

[no111u3]

It makes library clear: you can extend and update fat fs crate without hw depends and you can improve hw support without changes in fat fs. So crate is staied commonly easy for use - you can create default feature flag for use another hw support, or you can support hw extension as in serilalization in serde.

[thejpster]

OK, so if embedded-sdmmc was left as a simple, high-level crate, I'm fine with the FAT implementation being booted off into fat-rs or something, where it can be consumed by other applications / crates without all the SD stuff coming along too.

[thejpster]

Likewise the SD over SPI protocol implementation, and any future SD over SD Bus implementation - they can be in other crates, as long as this crate brings it all together is a nice easy to use format.

[elpiel]

I'd like to continue this discussion but instead of splitting it up, let's create a feature for enabling the fs for fat32 & fat16.

This will allow people to still depend on the crate for raw access, like for using it with e.g. littlefs2

[thejpster]

But if you don't use the FAT32 code, it all gets dead-code eliminated, doesn't it?

[qwandor]

I'm also interested in using the FAT32 part of this crate without the SD card part. In particular I'm looking at using it on top of a VirtIO block device using https://docs.rs/virtio-drivers/latest/virtio_drivers/device/blk/struct.VirtIOBlk.html. VirtIO also uses 512 byte sectors so that seems reasonable.

How would you feel about moving the BlockDevice trait into embedded-io? It seems like a useful abstraction that would make sense for other filesystem implementations too. There is also the block-device crate, but it looks like it hasn't been updated in a while or used very widely, so I think embedded-io makes more sense, if they will accept it.

[thejpster]

I wouldn't want to drop the BlockDevice trait but I'm happy to see a PR that implements it for any T: embedded::io::Read + Write + Seek if that's useful to you.

You could also implement those traits on our File objects. Which I think would let you mount a disk, and then mount a disk image on that disk.

Edit: I misread. You want to add a BlockDevice trait TO embedded-io. I'm fine with that.

[thejpster]

As an aside I wrote a VirtIO vring implementation in Rust from scratch in 2018 to do inter core RPC on a Beagleboard X15. Glad there's crate for it now! It was a doozy.

https://github.com/cambridgeconsultants/rust-beagleboardx15-demo/blob/master/bare-metal/ipu-demo/vring/src/lib.rs

[qwandor]

Edit: I misread. You want to add a BlockDevice trait TO embedded-io. I'm fine with that.

I'd like to add a BlockDevice trait to embedded-io (or possibly embedded-storage), and then use that here in embedded-sdmmc-rs in place of the trait you currently have in this crate. I then plan to implement the new BlockDevice trait in other crates, to allow them to be composed with this crate in either direction.

[thejpster]

Sounds fine to me.

[qwandor]

I sent rust-embedded-community/embedded-storage#59 to add the trait to the embedded-storage crate.