(Cc: Lyude) On Fri Jan 30, 2026 at 9:34 AM CET, Eliot Courtney wrote: > This series extends the DMA coherent allocation API to support compile-time > known sizes. This lets bounds checking to be moved from runtime to build > time, which is useful to avoid runtime panics from index typos. It also > removes the need for a Result return type in some places. > > The compile time size is specified via a marker type: StaticSize<N>. > Statically sized allocations can decay to runtime sized ones via deref > coercion for code that doesn't need to know the size at compile time, or to > avoid having to carry around extra type parameters. The implementation > follows a similar pattern to Device/DeviceContext. > > The series defines three type aliases: CoherentSlice<T> (for runtime size), > CoherentArray<T, N> (for compile-time size N), and CoherentObject<T> (for > single object allocations). It also adds infallible dma_read!/dma_write! > macros and methods to CoherentArray, while prefixing the existing fallible > methods and macros with `try_`. > > The macros keep the same syntax (i.e. > coherent_allocation[index].optional_fields = expression) even for > CoherentObject, because the [] syntax is needed to know where to split the > actual CoherentAllocation object from the fields. This means that > CoherentObject is indexed with [0] in dma_write!/dma_read! macros. The > alternative is defining a separate macro for single object access, but it > still would need a way to delineate between the allocation and the fields, > perhaps by using commas (dma_read_obj!(object, fields), > dma_write_obj!(object, fields, value)). This would be inconsistent with the > array/slice syntax.
We've just generalized I/O to support arbitrary I/O backends (busses, backing storage, etc.). With this we can wire up the I/O traits to DMA and generalize the dma_read() and dma_write() macros accordingly. I.e. we can extend the I/O traits with field_write() and field_read(). (Lyude is going to work on this as a more integrated alternative to iosys_map. It would be good to align with her regarding this work.) This has the advantage that we don't have to duplicate all this infrastructure for I/O memory, DMA, etc. I also think that CoherentSlice is too specific of a type. I'd rather have a generic type, maybe UnsafeSlice or IoSlice, that just uses the I/O backend for accesses.
