On Sat Jan 31, 2026 at 9:27 PM JST, Danilo Krummrich wrote: > (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().
With the caveat that the I/O traits for now only support accessing primitive types; is the plan to add a function to read any type implementing `FromBytes`? > > (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.) Heads up, I am also doing some plumbing in `io.rs` related to the register macro. Maybe we should have a thread on Zulip to discuss what everyone is working on. > > 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. For me the main appeal of this patchset is that it provides a way to work infallibly with a single object or a fixed-size array. I hope that's something we can preserve.
