Support sending can frames over tokio canfd sockets (Resolves #57) #69
Conversation
EliteTK
force-pushed
the
tokio-canfd-can
branch
2 times, most recently
from
f86f823 to
2ca84a4
Compare
|
Actually, looks like #68 already addresses the unnecessary path component issue and #61 addresses the panic. Feel free to just merge those first and I'll drop the commits from this PR. #67 would clash with this change but I don't mind re-doing it if you were to apply it first. Technically with #67 it would become quite easy to also make write_frame take a Anyway, let me know, this isn't particularly urgent right now. |
|
I've actually gone ahead and rebased things on top of the other PRs. Applying this (which is now breaking) will also include #68, #61, and #67 (the authorship information is preserved so while the PRs won't get auto-closed as merged, the contributors aren't being stiffed). But feel free to just apply those PRs individually prior to this one. I just did this so I could develop on top of #67 and didn't step on #68 and #61's toes. I've also added a fix for the Stream impl as well as even more tests. |
This is a breaking change. This also adds tests for all the additional cases (although no mixed tests so far).
EliteTK
force-pushed
the
tokio-canfd-can
branch
from
0495fda to
84ace4c
Compare
|
I've now rebased against all the accepted PRs and force pushed the new version of my commit. |
|
Nice! |
Ah, don't worry about that. I don't mind it. |
|
I came across the same issue with the tokio API and tested out this PR. It works very well (thanks @EliteTK). Would really appreciate getting it merged and officially released. |
|
Yes, apologies. A new release is overdue. I'm at RustConf this week, but will get a few of these PRs landed and tested when I return, and publish a new version. |
|
Just a friendly ping on this PR, which is needed to send CAN frames on CAN-FD interfaces. |
The first patch is unrelated and is just a cleanup of a bunch of extraneous path components. I couldn't compile without removing these first.
I think this is probably an acceptable solution. This also fixes #57.
Please let me know what you think. I can probably test this on real hardware soon but the new tests pass (although they currently seem to omit actually verifying that the received frame is of the right type and content etc).