-
-
Notifications
You must be signed in to change notification settings - Fork 779
Description
With the last Rust update, we added a clippy allow
to let some current, lesser-used, chip-specific code not block the update, specifically:
#4442 (comment)
Looking at this quickly, it looks like clippy did identify a real concern, so I'm lifting it out to an issue to not get lost.
With the current code, get_slot_buffer
has to trust that there isn't any code path which either (a) accidentally lets two TXes run in flight concurrently, or (b) that RX never tries to re-use a slot. It probably does work currently, but it's hard to follow, and at-minimum a // SAFETY
comment (in a few places on the TX/RX path probably) would go a long way to explaining how it's currently sound.
Better would probably be something that constructs slots statically (const generics? one-off macro? it doesn't look like slot_size
changes anyway [boards/litex/arty/src/litex_generated_constants.rs:pub const ETHMAC_SLOT_SIZE: usize = 2048;
, boards/litex/sim/src/litex_generated_constants.rs:pub const ETHMAC_SLOT_SIZE: usize = 2048;
]), and wraps with TakeCell
s to access or similar.