the curve 25519 accelerator hw is different on different targets
so it can't be enabled for all of them all at once.
This is going to be come a bigger problem as time goes on...
flatipc is a new method for doing IPC. This is a zero-copy approach
where structs are given `repr(C)` implementations that are well-defined
and work across process boundaries.
If the same struct or enum is used in two processes that has the same
layout, then data can be freely passed between the two processes without
incurring a serialization or deserialization penalty, provided the
following hold:
1. The buffer must be page-aligned and be a multiple of the page size
2. The item must be `#[repr(C)]`
3. There must be no pointers or references of any kind
If these three things hold, then the object is safe to sling across the
process boundary.
This crate adds the ability to annotate structs with
`#[derive(flatipc::Ipc)]` to provide them with this functionality. When
doing so, objects gain the `.into_ipc()` call that turns them into
something that can be sent across process boundaries.
The resulting object has `.lend()`, `.lend_mut()`, `.try_lend()`, and
`.try_lend_mut()` as functions.
Signed-off-by: Sean Cross <sean@xobs.io>
The purpose of the planning directory is a place where we can stash
code for reference in various github issues and project plans without
having to integrate it into the code base. This is for large changes
to the code base that require extensive planning and discussion prior
to integration.
this is the hub service for all the cramium-soc global hardware
issues. Kind of like the equivalent of `llio` on Precursor, but
hopefully slightly better thought-out.
The first service implemented here is an IFRAM allocator, which
is essential for all things DMA and UDMA.
