Support for dynamic BLOCK_COUNT

[jonas-schievink]

Currently the user has to statically know the device size since BLOCK_COUNT is an associated constant. It would be useful if it would be possible to dynamically determine the device size instead.

[nickray]

I agree, mount should read it from the metadata (where I believe it's stored), and format should take it as parameter.

[nickray]

Missing upstream: littlefs-project/littlefs#349

[TheTechRobo]

Is it possible to pass the block count to the function at runtime if I know it, even if littlefs doesn't? Currently it seems I have to hardcode the volume size. I am developing for ESP32, and littlefs is using one partition of the flash. I can read the partition table, which gets me the length, and using that would make me feel much better than hardcoding the size.

If I've missed something please let me know!

[robin-nitrokey]

Unfortunately this is currently not possible. We could remove all associated constants from the Storage trait and pass them to Allocation::new instead. The only downside is that the storage implementation could be called with unexpected offsets and block sizes, but it should probably validate those anyway.

[TheTechRobo]

That seems like a good idea to me. It would allow for reading any filesystem discovered at runtime, rather than just ones the developer thought of.

It is not a serious issue in my case: I came up with a workaround where the app reads the partition table and makes sure the hardcoded values are correct, which is robust enough for me. But it would be a nice feature.

The only downside is that the storage implementation could be called with unexpected offsets and block sizes, but it should probably validate those anyway.

Maybe constants vital to the Storage implementation (like block size) could be put in the trait? That would remove some flexibility, though.

[robin-nitrokey]

Maybe constants vital to the Storage implementation (like block size) could be put in the trait?

Isn’t that what we have right now?

[TheTechRobo]

I meant the ones that are hardware-dependent, like block size. But rethinking it, yeah, it should probably be all or nothing, and force the Storage implementer to do validation.