MAX_MESSAGE_SIZE configuration granularity is insufficient

[chrysn]

There's a note in shared:

// TODO: find a way to configure the buffer size

The current workaround is to have a feature quadruple_sizes that scales everything up; turns out that for at least one application, 4x is so large it smashes the stack, and 1x is too small for ACE tokens.

I've played around with envinroment variables, and found something that works:

-// TODO: find a way to configure the buffer size
-// need 128 to handle EAD fields, and 192 for the EAD_1 voucher
-pub const MAX_MESSAGE_SIZE_LEN: usize = SCALE_FACTOR * (128 + 64);
+pub const MAX_MESSAGE_SIZE_LEN: usize = if let Some(e) = option_env!("LAKERS_MAX_MESSAGE_SIZE") {
+    match konst::primitive::parse_usize(e) {
+        Ok(n) => n,
+        Err(_) => panic!("Error parsing LAKERS_MAX_MESSAGE_SIZE"),
+    }
+} else {
+    // need 128 to handle EAD fields, and 192 for the EAD_1 voucher
+    SCALE_FACTOR * (128 + 64)
+};

But I'm not happy with that: It requires the environment variable to be set from outside, and that means that the crate that has the requirement somewhere down in the tree needs to parse the environment variable as well, and complain, and then the user has to call it with some variable … nah.

I do now think that the better form is to have granular lakers_max_message_size_256 etc. features, in arbitrary steps, which can be selected by downstream crates; that seems to be the common practice in other embedded crates as well.

A prettier solution is of course to introduce generics, but that'll need more changes, and I'd rather have something working soon.

[chrysn]

Two things I've added:

• Features for other buffer sizes I ran into
• I've moved the branch onto 0.7.2. It works with main too, so merging it is fine, but to avoid working from different APIs, I need it to be usable before the message 4 API change was merged.

[geonnave]

Thanks for raising this and referencing embassy-executor. This approach seems fine to me.