Expose len8_dlc field of can_frame struct.
#3357
Conversation
|
r? @JohnTitor (rustbot has picked a reviewer for you, use r? to override) |
de-vri-es
changed the title
len8_dlc field of can_frame struct.
|
@bors r+ |
Expose `len8_dlc` field of `can_frame` struct. The `can_frame` struct on Linux has a `len8_dlc` field which can be used to stuff a few extra bits in the `dlc` field of the actual CAN frame on the wire (only allowed when the data length itself is 8, and if the hardware CAN controller allows it). However, that field is not currently exposed. This PR exposes it as `pub len8_dlc: u8` so we can get those extra 2.8 bits from our CAN frames 😅 It would have been nice to name the current `can_dlc` field as `len`, instead of the old deprecated name, but I guess that ship has sailed. Upstream documentation: https://www.kernel.org/doc/html/latest/networking/can.html#how-to-use-socketcan > ```c > struct can_frame { > canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */ > union { > /* CAN frame payload length in byte (0 .. CAN_MAX_DLEN) > * was previously named can_dlc so we need to carry that > * name for legacy support > */ > __u8 len; > __u8 can_dlc; /* deprecated */ > }; > __u8 __pad; /* padding */ > __u8 __res0; /* reserved / padding */ > __u8 len8_dlc; /* optional DLC for 8 byte payload length (9 .. 15) */ > __u8 data[8] __attribute__((aligned(8))); > }; > ``` > > Remark: The len element contains the payload length in bytes and should be used instead of can_dlc. The deprecated can_dlc was misleadingly named as it always contained the plain payload length in bytes and not the so called 'data length code' (DLC). > > To pass the raw DLC from/to a Classical CAN network device the len8_dlc element can contain values 9 .. 15 when the len element is 8 (the real payload length for all DLC values greater or equal to 8).
|
💔 Test failed - checks-actions |
|
I don't see any reason for the failure. Is it correct to assume that this was an unrelated CI failure? :o |
de-vri-es
force-pushed
the
can-frame-len8-dlc
branch
from
85dbb12
to
1f88773
Compare
|
The failure is related. I think mips doesn't have it or our musl header is too old. |
|
Oh, sorry, the link just pointed to a job running "exit 1" and I didn't notice the other red check. |
|
Note that the What would be a good way forward for me to unblock this? Find a different linux mips distro with a newer kernel? /edit: This openwrt release would fit the bill: https://downloads.openwrt.org/releases/23.05.0-rc4/targets/bcm47xx/generic/openwrt-sdk-23.05.0-rc4-bcm47xx-generic_gcc-12.3.0_musl.Linux-x86_64.tar.xz |
|
Hmm, updating to https://downloads.openwrt.org/releases/23.05.0-rc4/targets/bcm47xx/generic/openwrt-sdk-23.05.0-rc4-bcm47xx-generic_gcc-12.3.0_musl.Linux-x86_64.tar.xz breaks other tests, atleast if I locally run I guess I need to figure out why first :( |
|
☔ The latest upstream changes (presumably #3429) made this pull request unmergeable. Please resolve the merge conflicts. |
The
can_framestruct on Linux has alen8_dlcfield which can be used to stuff a few extra bits in thedlcfield of the actual CAN frame on the wire (only allowed when the data length itself is 8, and if the hardware CAN controller allows it).However, that field is not currently exposed. This PR exposes it as
pub len8_dlc: u8so we can get those extra 2.8 bits from our CAN frames 😅It would have been nice to name the current
can_dlcfield aslen, instead of the old deprecated name, but I guess that ship has sailed.Upstream documentation: https://www.kernel.org/doc/html/latest/networking/can.html#how-to-use-socketcan