-
Notifications
You must be signed in to change notification settings - Fork 666
Conversation
1a841c3 to
8d47c73
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Zstandard addition should be a distinct commit. Please let me know if you would like to merge with squashing so that I can split it out into a new PR
8d47c73 to
835e588
Compare
It is useful for both using SocketCAN devices and pcap(ng) files storing SocketCAN packets
835e588 to
3e549a5
Compare
zariiii9003
commented
May 30, 2025
Keep the changes minimal. Move the socketcan files back to where they belong, remove zstd and all other unrelated changes. Add test data and documentation (see file_io.rst)
dsseng
commented
May 30, 2025
Keep the changes minimal. Move the socketcan files back to where they belong, remove zstd and all other unrelated changes. Add test data and documentation (see file_io.rst)
I abstracted out some common SocketCAN files for the purpose of not duplicating the code. pcapng expects packets to be serialized as SocketCAN packets, so this code has to be shared. Let me know if there is a better place or way to refactor this.
zariiii9003
commented
May 30, 2025
you could just import from socketcan without moving the files
dsseng
commented
May 30, 2025
you could just import from socketcan without moving the files
Is this a correct pattern for an IO module to import an interface module? That felt a bit counter-logical
Uh oh!
There was an error while loading. Please reload this page.
This PR adds support for Pcapng files to the I/O module
Related to #1403, pcap should be rather simple to implement based on these changes.
TODO:
(削除) lz4 (削除ここまで), zst, perhaps other compression types readers know about