Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

bradjc
Copy link
Contributor

@bradjc bradjc commented Jun 4, 2024

Pull Request Overview

This pull request adds a new 802.15.4 syscall driver that does not handle and framing or packet processing in the kernel. It uses the radio HIL directly. This is useful for running networking stacks like OpenThread in userspace.

Testing Strategy

Testing as part of the full series of 15.4 changes.

TODO or Help Wanted

Need to update the other 15.4 driver with the new commands.

Need to figure out what to name this.

Documentation Updated

  • Updated the relevant files in /docs, or no updates are required.

Formatting

  • Ran make prepush.

@github-actions github-actions bot added component WG-Network In the purview of the Network working group. labels Jun 4, 2024
bradjc added 2 commits June 4, 2024 15:48
This avoids all of the MAC layers, framing, etc. and works with the
radio directly.
@bradjc
Copy link
Contributor Author

bradjc commented Jun 5, 2024

Ok I pushed a commit that fixed the bug I was having. I've now tested this with the libtock-c radio_raw_tx and radio_rx apps and I'm getting packets from one device to the other.

//! ```
//!
//! `user_frame` denotes the 15.4 frame in addition to the relevant 3 bytes of
//! metadata (offset to data payload, length of data payload, and the MIC len).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where in user_frame are these 3 relevant bytes?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The answer is on line 354, but that won't be exported to documentation. Worth just repeating that comment here IMO.

//! be passed to the process. The ring buffer is designed to overwrite old
//! packets if the buffer becomes full. If the process notices a high number of
//! "dropped" packets, this may be the cause. The process can mitigate this
//! issue by increasing the size of the ring buffer provided to the capsule.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This paragraph mixes description with justification in a way that's a bit confusing. Would probably be better to split them up. Sometimes I want to just know what the interface is and I only separately care about why this is the interface.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This text was already merged before, we use the same logic for the other syscall driver. I didn't create or write this.

Copy link
Member

@alevy alevy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This generally looks pretty good to me, some inline comments that I'm medium requesting to address.

@alevy alevy added this pull request to the merge queue Jun 6, 2024
Merged via the queue into master with commit 0252cda Jun 6, 2024
@alevy alevy deleted the 154-phy-driver branch June 6, 2024 16:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component WG-Network In the purview of the Network working group.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants