Tracking: OpenThread Support

[tyler-potyondy]

Tracking: OpenThread Support

[bradjc]

Ideally these changes should be entirely abstracted from userland.

The easiest path is to have two separate SyscallDriver implementations which expose (mostly) the same interface. A more complicated approach would have a single SyscallDriver implementation that supports using either a MacDevice or a hil::radio::Radio. Unfortunately this in general is a limitation in Tock as there is not a clean way to shim layers at the SyscallDriver layer.

One thing to note is that currently the virtualization in this stack is within the kernel and not for userspace. Adding userspace virtualization would make this more complicated, as that really only applies to the in-kernel MAC stack.

While a singe userspace driver would be nice in some respects, I'm not inclined to purse that for two reasons: 1) Sending raw MAC-layer frames from userspace seems, practically speaking, a niche use case, and 2) It adds a fair bit of complexity to the implementation which is otherwise simpler to read and write as separate drivers. Note, we can keep the interface the same so userspace has only one driver and gets the errors as you describe. It's just that the correctness of that is harder to maintain over time (every change would need to be ported to both syscall drivers).

[alevy]

100% two separate drivers for two different use cases.

The current driver is really a work-in-progress towards a network stack implemented in the kernel and virtualized to applications at the level of something like sockets.

The new driver should be a raw interface that is available to a limited set of processes (probably exactly one, but I can imagine maybe wanted a coordinating set of processes), where the network is virtualized to other processes via IPC.

These are two totally different use cases and they have almost no reason to co-exist on the same board at the same time.

[alevy]

This would be good to parallelize with a Rust userland interface for such a raw driver. I can maybe take that portion on if I coordinate with @tyler-potyondy, especially visa vis testing.

/cc @wprzytula

[bradjc]

What is

libtock-c specific OpenThread radio functionality

?

[bradjc]

For the flash storage, what is required? How many bytes do we need to store?

[tyler-potyondy]

What is

libtock-c specific OpenThread radio functionality

?

This was referring to implementing the OpenThread radio PAL in libtock-c (I was trying to draw a distinction between the capsule / libtock-c milestones). I've rephrased to hopefully make this more clear.

[tyler-potyondy]

For the flash storage, what is required? How many bytes do we need to store?

I do not have an exact answer for now. Briefly checking, it appears on the order of ~24kB persistent storage is expected. @Samir-Rashid and @atar13 just began working on the flash PAL so we should have more ideas as to what is required soon. I do not expect flash functionality to be a blocker for Thread functioning as it serves to provide persistence to the Thread state across power cycles. This will however be necessary to comply with the Thread spec for any future Thread certification.

[bradjc]

I do not have an exact answer for now. Briefly checking, it appears on the order of ~24kB persistent storage is expected.

Ok that is quite a bit. We do have https://github.com/tock/tock/blob/master/capsules/extra/src/nonvolatile_storage_driver.rs which might work for a userspace interface.

I do not expect flash functionality to be a blocker for Thread functioning as it serves to provide persistence to the Thread state across power cycles.

I don't know what this looks like in practice, but it seems like a device should be able to reboot and reconnect as expected. It would be good to avoid having to make any caveats about how things don't quite work as expected. But maybe you can't really tell as a user what happens if you don't have persistent state.

[alevy]

Getting close!

• 15.4 capsule support for changing radio channel
• 15.4 capsule RSSI getting / setting
• ibtock-c OpenThread radio PAL

[bradjc]

I think there is a fundamental mismatch with trying to use OpenThread in userspace with the capsules/extra/ieee802154/driver.rs syscall driver. That driver is built on this stack:

┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ Syscall Interface
┌──────────────────────┐
│     RadioDriver      │
└──────────────────────┘
┄┄ ieee802154::device::MacDevice ┄┄
┌──────────────────────┐
│      VirtualMac      │
└──────────────────────┘
┄┄ ieee802154::device::MacDevice ┄┄
┌──────────────────────┐
│        Framer        │
└──────────────────────┘
┄┄ ieee802154::mac::Mac ┄┄
┌──────────────────────┐
│  MAC (ex: AwakeMac)  │
└──────────────────────┘
┄┄ hil::radio::Radio ┄┄
┌──────────────────────┐
│    802.15.4 Radio    │
└──────────────────────┘

however the lower layer of OpenThread does not expect to sit on any of those layers except for the radio. For the tutorial we essentially added a raw path through those layers. However, that still doesn't allow configuring the channel. Instead, I propose:

• Restore the previous 15.4 stack, but keep the LQI change:
  • Revert #3985 (in #3995)
  • Revert #3851 (https://github.com/tock/tock/tree/ieee802154-revert-send-raw)
  • Revert #3919 (https://github.com/tock/tock/tree/revert-enc-recv)
• Write a new syscall driver that uses hil::radio::Radio. This can add back channel control and the ability to turn on/off the radio. (https://github.com/tock/tock/tree/ieee802154-phy-driver)
• Back port (most of) the additions in the new syscall driver to the existing one so that we can use the same userspace library for both.

[tyler-potyondy]

I am overall in favor of this. The current 15.4 stack is not conducive to supporting OpenThread and we are forcing a square peg into a round hole so to speak. In my opinion, the two routes forward at this juncture are either:

1. Redesign the 15.4 stack into a unified stack that is able to somehow satisfy the needs @bradjc highlights here. It is not exactly clear if it is possible to support both or if this is even an optimal design.
2. Implement a separate 15.4 driver that offers full control of the radio as @bradjc proposes above.

I favor option two because I think this provides an easier path forward to more fully support the features OpenThread requires (sleeping / channel switching etc). These features become increasingly complicated to reason about across virtualized 15.4 access with multiple apps.

Some things to keep in mind with option two are that:

• This will be mutually exclusive with the existing 15.4 stack .
• This will require configuring the kernel differently to use OpenThread apps vs the current 15.4 test apps (i.e. setting a different client for the radio).

Ideally these changes should be entirely abstracted from userland. Perhaps we should only expose one 15.4 userspace driver that then will interface to the "non virtualized full control" 15.4 driver or the "virtualized stack" depending on how the kernel is configured.

┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ Syscall Interface
┌──────────────────────────────────────────────┐
│     RadioDriver                              │
└──────────────────────────────────────────────┘
(DEPENDENT ON WHICH CLIENT IS SET SELECTS ONE OF TWO "STACKS")
┌──────────────────────┐┌──────────────────────┐
│      VirtualMac      ||    802.15.4 Radio    │
└──────────────────────┘└──────────────────────┘
┌──────────────────────┐
│        Framer        │
└──────────────────────┘
┌──────────────────────┐
│  MAC (ex: AwakeMac)  │
└──────────────────────┘
┌──────────────────────┐
│    802.15.4 Radio    │
└──────────────────────┘

With this design we can then return an error to userland if the full radio control "non virtualized" design is configured and multiple apps request 15.4 access. Furthermore, we can also easily return an error to userland if things such as switching channels or setting radio transmit power etc are attempted to be set in the virtualized mutli app design.

[tyler-potyondy]

@bradjc have you begun working on a "direct driver" implementation? If not, I can put this together this upcoming week and we can revert the PRs you mentioned.

[bradjc]

Yes in branch linked above