trussed-dev
Remove need for generic array and typenum constants
This also allows for more flexible Storage implementations that use Vec<u8> as a cache buffer and are not fixed to a single block size, this is used in the list example to allow listing filesystem with varying block sizes without requiring recompilation.
Since the default values were mostly targetted for our lpc55 use case and made it annoying to debug the nrf version that has a smaller block size, I wanted to make it easier to switch between the two.
This can be useful for a lot of host tooling that could not be made previously.
I think this is the right approach to get rid of the configuration constants. What do you think about using a Config or StorageConfig struct and a single Storage::config function instead of having separate functions for every configuration? That would make it easier to implement the trait, especially if the values are configurable like in the list example.
That does seem better overall but on the other hand it does not allow for default values, which we make use of.
One could argue it's better anyway because users should be aware of default values.
It also means that we can't add new fields with default values without it becoming a breaking change
Some changes:
- Made
set_lenfaillible - Added an
empty()constructor - Made
set_lenbe called on Filesystem initialization andFileAllocationusage.cache_sizeis still cached to avoid it changing and causing UB. This allows the creation of the allocation to still be infaillible, not changing the usage API. In case of failure to allocate the required capacity, we returnNO_MEMORYinstead of panicking.
Checked that it works in our full firmware with https://github.com/Nitrokey/nitrokey-3-firmware/pull/613
There is one issue: it makes it not possible to have the exact same READ_SIZE/BLOCK_SIZE values for the "OptionalStorage", but I'm not sure that's that much of a loss. A solution could be to have two traits. One with constants, and one with functions, and have a blanket implementation of the function one for implementers of the constants one.
Not sure it's that worth it. It would also require re-adding GenericArray as a dependency.
I also thought about a trait with constants so that implementations that use constant values anyway can opt into compile-time checks of the configuration. But the generic-array requirement is not ideal, so I’m not sure about it.
I updated https://github.com/Nitrokey/nitrokey-3-firmware/pull/613 on top of main, It works so I think we can merge this and maybe prepare a new release of littlefs2 (I don't think we should merge it into the firmware until we released 1.8.2 stable and nkpk update though).