You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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.
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.
Any indication of when this might be supported? I've just ran into the same problem developing for the ESP32 - where the parition table tells me how long the filesystem is.
Activity
nickray commentedon Mar 3, 2020
I agree,
mountshould read it from the metadata (where I believe it's stored), andformatshould take it as parameter.nickray commentedon Mar 5, 2020
Missing upstream: littlefs-project/littlefs#349
Merge pull request trussed-dev#2 from Nitrokey/callbacks
TheTechRobo commentedon Jan 19, 2025
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 commentedon Jan 20, 2025
Unfortunately this is currently not possible. We could remove all associated constants from the
Storagetrait and pass them toAllocation::newinstead. 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 commentedon Jan 20, 2025
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.
Maybe constants vital to the Storage implementation (like block size) could be put in the trait? That would remove some flexibility, though.
robin-nitrokey commentedon Jan 20, 2025
Isn’t that what we have right now?
TheTechRobo commentedon Jan 20, 2025
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.
Dominaezzz commentedon Mar 17, 2025
Would a PR for this be accepted? To turn all the
consts in the trait into non-constfunctions?Dominaezzz commentedon Mar 17, 2025
Oh someone has made a PR already #101
TheEnbyperor commentedon Aug 23, 2025
Any indication of when this might be supported? I've just ran into the same problem developing for the ESP32 - where the parition table tells me how long the filesystem is.