Add support for listing configs

[sosthene-nitrokey]

Depends on

• Add command to list configuration options admin-app#29

[nitrokey-ci]

No significant changes.

Insignifcant changes

metric	value		change
binary-size-nk3am	1,441,021	🔴	+1,260 (+0.09%)
binary-size-nk3am-test	2,049,743	🔴	+1,890 (+0.09%)
binary-size-nk3xn	516,884	🔴	+576 (+0.11%)
binary-size-nk3xn-test	591,080	🔴	+576 (+0.10%)
binary-size-nkpk	747,970	🔴	+1,575 (+0.21%)

[robin-nitrokey]

I wonder where the 6k binary size is coming from. My first guess was serialization, and we could offload that to a macro or build script, but a quick test replacing the fields with an empty slice only yields less than 500 bytes. Very confusing.

[sosthene-nitrokey]

My guess is the added serialization to a heapless::Vec<u8, N> in cbor-smol, which wasn't there in the past? Since the constant and the serialization are defined in completely different crates it could be possible that the constant is not inlined/optimized out?

[robin-nitrokey]

Ah, by using upstream cbor-smol instead of our fork you basically reverted Nitrokey/cbor-smol#3 and Nitrokey/cbor-smol#4.

[sosthene-nitrokey]

Normally I added both back. The patch points to trussed-dev/cbor-smol#14 and trussed-dev/cbor-smol#8 implements #3

[sosthene-nitrokey]

It didn't fit without.

[robin-nitrokey]

Oh, sorry, I must have ended up on the wrong branch. Anyway, just applying the cbor-smol patch on top of main causes a similar size increase as this PR. Maybe it’s trussed-dev/cbor-smol#8? The heapless change shouldn’t have any effects until it is used, no? I’ll prepare PRs to merge the size optimizations upstream so that we can release 0.4.1 and have a clean baseline.

[sosthene-nitrokey]

The heapless change is used in admin app (because ctaphid-dispatch uses Vec<u8, N> and not Bytes for the response buffer.

[sosthene-nitrokey]

I think I found a way to improve that by making the heapless-bytes implementation fall back to the heapless implementation.

[robin-nitrokey]

Starting from the current main (fca2d32), I get these numbers for NK3xN with test:

• v0.4.0-nitrokey.4: 590,440
• trussed-dev/cbor-smol@2ba6ee3: 592,136
• trussed-dev/cbor-smol@e2ad859: 590,360
• trussed-dev/cbor-smol@4bf2788: 592,184 (with heapless-bytes-v0-3)
• trussed-dev/cbor-smol@f117b49: 592,376 (with heapless-bytes-v0-3)

Conclusions:

1. In the original patch Never inline map value deserialization trussed-dev/cbor-smol#14, you only included Never inline map value deserialization cbor-smol#1 (map value deserialization) but not Never inline map and tuple deserialization cbor-smol#4 (map and tuple deserialization). This probably caused the 6k increase.
2. Updating to upstream still causes a 2k increase – PR 4 actually reverted PR 1 which I missed when re-applying the patches. Indeed, after reverting the change, we are back at the original size (or even slightly smaller).
3. The size optimization in Add support for multiple heapless and heapless-bytes versions trussed-dev/cbor-smol#13 has an adverse effect.

[robin-nitrokey]

LGTM, thank you! It looks like the CI is confused because #539 includes the same commit – to be investigated.

[robin-nitrokey]

unused patch

[robin-nitrokey]

We could directly replace this with a cbor_serialize into an array so that we don’t have to update it in the future (and we don’t need to add the explicit heapless_bytes dependency).