You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure if the Rust type layout guarantees this, since all contexts are mere wrappers of [u32;8] or other contexts which means we only have 4-byte alignment.
For output(device) context, DCBAA spec requires that the context pointer should be 64-byte aligned, but naively decorating #[repr(C, align(64)] to Device<N> results in 32-byte padding between Input control context and device context fields (assuming 32-byte contexts).
For this, I think we have two choices:
Add a Output context type which is a mere wrapper for the device context, except with 64-bit alignment guarantee.
The Output context here should be defined like:
#[repr(C, align(64))]#[derive(Copy,Clone,Debug,Ord,PartialOrd,Eq,PartialEq,Hash)]pubstructOutput<constN:usize>{device:Device<N>,}impl_constructor!(Output,"Output");impl<constN:usize>Output<N>{constfnnew() -> Self{Self{device:Device::new(),}}}impl<constN:usize>OutputHandlerforOutput<N>{fndevice(&self) -> &dynDeviceHandler{&self.device}fndevice_mut(&mutself) -> &mutdynDeviceHandler{&mutself.device}}/// A trait to handle Output Context.pubtraitOutputHandler{/// Returns a handler of Device Context.fndevice(&self) -> &dynDeviceHandler;/// Returns a mutable handler of Device Context.fndevice_mut(&mutself) -> &mutdynDeviceHandler;}
It is questionable that whether we really need OutputHandler (impl DeviceHandler for Output will do all works) though.
A thought about the last line, irrelevant to this issue
`InputHandler` itself is something redundant just as the above `OutputHandler` is, since we can implement `InputControlHandler` and `DeviceHandler` directly for input contexts.
impl<constN:usize>InputControlHandlerforInput<N>{}// already impl'ed in trait def. Needs impl `AsRef<[u32]>` and `AsMut<[u32]>` for `Input<N>`.impl<constN:usize>DeviceHandlerforInput<N>{fnslot(&self) -> &dynSlotHandler{&self.device.slot}fnslot_mut(&mutself) -> &mutdynSlotHandler{&mutself.device.slot}fnendpoint(&self,dci:usize) -> &dynEndpointHandler{Self::assert_dci(dci);&self.device.endpoints[dci - 1]}fnendpoint_mut(&mutself,dci:usize) -> &mutdynEndpointHandler{Self::assert_dci(dci);&mutself.device.endpoints[dci - 1]}}
Split slot and EP contexts out of device context in Input context definition. This is a breaking change.
In this case, the definitions should be like this:
For input contexts, the input context pointer should be 16-byte aligned.
So the proper definition of input context would be:
I'm not sure if the Rust type layout guarantees this, since all contexts are mere wrappers of
[u32;8]
or other contexts which means we only have 4-byte alignment.For output(device) context, DCBAA spec requires that the context pointer should be 64-byte aligned, but naively decorating
#[repr(C, align(64)]
toDevice<N>
results in 32-byte padding between Input control context and device context fields (assuming 32-byte contexts).For this, I think we have two choices:
Output
context type which is a mere wrapper for the device context, except with 64-bit alignment guarantee.The
Output
context here should be defined like:It is questionable that whether we really need
OutputHandler
(impl DeviceHandler for Output
will do all works) though.A thought about the last line, irrelevant to this issue
`InputHandler` itself is something redundant just as the above `OutputHandler` is, since we can implement `InputControlHandler` and `DeviceHandler` directly for input contexts.
In this case, the definitions should be like this:
The text was updated successfully, but these errors were encountered: