Port NRF Serialization to 2.0 #2393

ppannuto · 2021-01-29T07:53:39Z

Pull Request Overview

This updates the nrf serialization to the 2.0 interface.

Testing Strategy

Tested on imix with the ble-uart test application and the nRF BLE sniffer app for an iPhone. The device advertises with an interval of 505ms.

TODO or Help Wanted

Not required, but figuring out why the ble-uart application throws an error, code 16835, would be good. The code in master throws this as well, so it's not blocking on this PR.

Documentation Updated

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

Formatting

Ran make prepush.

phil-levis

I can imagine that we might want a map and mut_map, but I think in this case you want to use mut_map_or in order to pass a useful value to userspace. With the current implementation, it's possible userspace passes a smaller buffer than what's received and you'll pass the complete receive length rather than what's copied. This will likely lead userspace to run off the end of the buffer.

capsules/src/nrf51822_serialization.rs

…ation-2.0

phil-levis · 2021-02-09T22:01:00Z

Working on this now.

phil-levis · 2021-02-10T02:46:14Z

I've updated this to use mut_map_or and pass lengths properly back to userspace.

I've also updated the libtock-c support to use the new APIS: https://github.com/tock/libtock-c/tree/nrf_serialization_2.0

However, it seems to fail immediately (simple_ble_init returns an error), and this occurs when registering a handler through SOFTDEVICE_HANDLER_INIT. I'd appreciate it if someone who is at last familiar with the NRF softdevices takes a look.

phil-levis

This still needs to be tested -- can't get the userspace library working.

phil-levis

Needs testing.

Should just be a comment.

bradjc · 2021-02-12T18:50:01Z

I had to make one change, removing the buffer length from the rx syscall. Otherwise I was able to make this interface work with libtock-c.

hudson-ayers

LGTM, I don't think Tock 2.0 requires that apps be able to specify a receive length

ppannuto

Okay github.

capsules/src/nrf51822_serialization.rs

ppannuto · 2021-02-12T20:50:29Z

capsules/src/nrf51822_serialization.rs

@@ -244,24 +281,26 @@ impl uart::ReceiveClient for Nrf51822Serialization<'_> {

        self.active_app.map(|appid| {
            let _ = self.apps.enter(*appid, |app, _| {
-                app.rx_buffer = app.rx_buffer.take().map(|mut rb| {
+                let len = app.rx_buffer.mut_map_or(0, |rb| {


I believe the len variable and the mut_map_or and later map_or are wrong here.

The comment below says Note: This indicates how many bytes were received by hardware, regardless of how much space (if any) was available in the buffer provided by the app.

But with the current code, if the rx_buffer is missing it will return 0 instead, and if it's too short, the later max_len will return the app's rx_buffer length, not the returned hardware length.

I think the fix is simply to remove the len variable, remove all of the _or's here, and pass rx_len in the callback below. I'm not going to push that fix without consensus though, as I think we'd be going back and forth if I did that..

Good point -- then we should pass both. I assume these semantics are there for the peculiarities of the nRF serialization library? I'd therefore recommend this become

app.callback.schedule(4, rx_len, len);

Having implemented a bunch of these capsules, I've come to think that a simple map is dangerous; the situations in which you want to plug away when there's nothing there is pretty narrow. The API you describe, in which the byte count is the number received by the hardware, rather than what's in the buffer, is fine as long as there is always a buffer (of known length) there. But this map indicates that there might not be; calling map prevents you from being able to detect an error case. It might be that we do not want to dig into the nRF code to handle this case right now, but I think it doesn't speak well for the kernel if we make it impossible to handle. map_or has the advantage that it forces you to think about this -- what if the buffer isn't there?

Fix comment to match implementation of new interface.

…-serialization-2.0

phil-levis · 2021-02-14T21:09:03Z

OK, this is now working. Thanks to @bradjc for suggesting to start first with porting the original subscribe-based reading API then transition it to using command to be in line with 2.0 semantics.

capsules/src/nrf51822_serialization.rs

kernel/src/mem.rs

alevy · 2021-02-15T02:19:15Z

This is great! (Modulo @hudson-ayers's comments)

Can we please squash these nine commits and rewrite a single descriptive commit message? They are kind of all over the place and ultimately the changes in the final diff are fairly self contained.

Otherwise, I think, good to merge

Co-authored-by: Hudson Ayers <[email protected]>

…-serialization-2.0

semantics of `subscribe` to no longer issue a read; this requires userspace to issue an additional `command` call to start the read.

…-serialization-2.0

…s the" This reverts commit 342396c.

…into nrf-serialization-2.0" This reverts commit 1ffd5de, reversing changes made to f9a79bf.

…ck/tock into nrf-serialization-2.0"" This reverts commit 562b32e.

…. Changes the"" This reverts commit 2625116.

phil-levis · 2021-02-15T06:49:20Z

Ugh. Because I pulled tock-2.0-dev into it back on the 9th, squashing is beyond my git abilities.

phil-levis · 2021-02-15T06:56:23Z

bors r+

bors · 2021-02-15T07:08:22Z

Build succeeded:

This is a reconstruction of the commits of GitHub Pull Request tock#2393 [1], given that this pull request introduced commits which reverted merge commits, cluttering the Git history. This includes the following commits, and is based on the raw diff instead: Brad Campbell (1): capsules: nrf-serialization: no recv length Pat Pannuto (1): kernel: add `map` to AppSlice interface nrf51822_serialization: port to 2.0 interface Update capsules/src/nrf51822_serialization.rs Philip Levis (13): Merge branch 'tock-2.0-dev' of github.com:tock/tock into nrf-serialization-2.0 Updating to use map_or to detect proper lengths. Formatting. ble-uart app in libtock-c now works. Merge branch 'nrf-serialization-2.0' of github.com:tock/tock into nrf-serialization-2.0 Update capsules/src/nrf51822_serialization.rs Cut the map methods. Merge branch 'nrf-serialization-2.0' of github.com:tock/tock into nrf-serialization-2.0 Transitions the nRF51 syscall capsule to the 2.0 APIs. Changes the semantics of `subscribe` to no longer issue a read; this requires userspace to issue an additional `command` call to start the read. Merge branch 'nrf-serialization-2.0' of github.com:tock/tock into nrf-serialization-2.0 Revert "Transitions the nRF51 syscall capsule to the 2.0 APIs. Changes the" Revert "Merge branch 'nrf-serialization-2.0' of github.com:tock/tock into nrf-serialization-2.0" Revert "Revert "Merge branch 'nrf-serialization-2.0' of github.com:tock/tock into nrf-serialization-2.0"" Revert "Revert "Transitions the nRF51 syscall capsule to the 2.0 APIs. Changes the"" [1]: tock#2393 Co-authored-by: Pat Pannuto <[email protected]> Co-authored-by: Philip Levis <[email protected]> Co-authored-by: Brad Campbell <[email protected]>

2393: Port NRF Serialization to 2.0 r=phil-levis a=ppannuto This updates the nrf serialization to the 2.0 interface. Tested on imix with the `ble-uart` test application and the nRF BLE sniffer app for an iPhone. The device advertises with an interval of 505ms. Not required, but figuring out why the `ble-uart` application throws an error, code 16835, would be good. The code in master throws this as well, so it's not blocking on this PR. - [x] Updated the relevant files in `/docs`, or no updates are required. - [x] Ran `make prepush`. Co-authored-by: Pat Pannuto <[email protected]> Co-authored-by: Philip Levis <[email protected]> Co-authored-by: Brad Campbell <[email protected]>

ppannuto added 2 commits January 28, 2021 23:44

kernel: add map to AppSlice interface

52b3f12

nrf51822_serialization: port to 2.0 interface

6f85074

github-actions bot added the kernel label Jan 29, 2021

bradjc added the tock-2.0 Issues and PRs related to Tock version 2.0. label Jan 29, 2021

phil-levis requested changes Jan 30, 2021

View reviewed changes

capsules/src/nrf51822_serialization.rs Show resolved Hide resolved

capsules/src/nrf51822_serialization.rs Outdated Show resolved Hide resolved

Merge branch 'tock-2.0-dev' of github.com:tock/tock into nrf-serializ…

0446d99

…ation-2.0

phil-levis added 2 commits February 9, 2021 18:41

Updating to use map_or to detect proper lengths.

e664b12

Formatting.

4ed8309

phil-levis marked this pull request as ready for review February 10, 2021 04:24

phil-levis previously approved these changes Feb 10, 2021

View reviewed changes

phil-levis assigned alevy, ppannuto and bradjc Feb 10, 2021

phil-levis reviewed Feb 10, 2021

View reviewed changes

capsules: nrf-serialization: no recv length

823e463

hudson-ayers approved these changes Feb 12, 2021

View reviewed changes

ppannuto commented Feb 12, 2021

View reviewed changes

ppannuto and others added 3 commits February 12, 2021 15:51

Update capsules/src/nrf51822_serialization.rs

f3de6ff

Fix comment to match implementation of new interface.

ble-uart app in libtock-c now works.

846789b

Merge branch 'nrf-serialization-2.0' of github.com:tock/tock into nrf…

37a4deb

…-serialization-2.0

hudson-ayers reviewed Feb 15, 2021

View reviewed changes

capsules/src/nrf51822_serialization.rs Outdated Show resolved Hide resolved

kernel/src/mem.rs Outdated Show resolved Hide resolved

phil-levis and others added 3 commits February 14, 2021 21:57

Update capsules/src/nrf51822_serialization.rs

7df42c7

Co-authored-by: Hudson Ayers <[email protected]>

Cut the map methods.

f9a79bf

Merge branch 'nrf-serialization-2.0' of github.com:tock/tock into nrf…

1ffd5de

…-serialization-2.0

github-actions bot removed the kernel label Feb 15, 2021

phil-levis added 4 commits February 14, 2021 22:02

Transitions the nRF51 syscall capsule to the 2.0 APIs. Changes the

342396c

semantics of `subscribe` to no longer issue a read; this requires userspace to issue an additional `command` call to start the read.

Merge branch 'nrf-serialization-2.0' of github.com:tock/tock into nrf…

7639fcd

…-serialization-2.0

Revert "Transitions the nRF51 syscall capsule to the 2.0 APIs. Change…

2625116

…s the" This reverts commit 342396c.

Revert "Merge branch 'nrf-serialization-2.0' of github.com:tock/tock …

562b32e

…into nrf-serialization-2.0" This reverts commit 1ffd5de, reversing changes made to f9a79bf.

github-actions bot added kernel chips/sam4l Change pertains to the SAM4L MCU. tock-libraries This affects libraries supported by the Tock project WG-OpenTitan In the purview of the OpenTitan working group. labels Feb 15, 2021

phil-levis added 2 commits February 14, 2021 22:35

Revert "Revert "Merge branch 'nrf-serialization-2.0' of github.com:to…

aaa3b43

…ck/tock into nrf-serialization-2.0"" This reverts commit 562b32e.

Revert "Revert "Transitions the nRF51 syscall capsule to the 2.0 APIs…

d70c0c0

…. Changes the"" This reverts commit 2625116.

github-actions bot removed WG-OpenTitan In the purview of the OpenTitan working group. kernel tock-libraries This affects libraries supported by the Tock project chips/sam4l Change pertains to the SAM4L MCU. labels Feb 15, 2021

bors bot merged commit bc69582 into tock-2.0-dev Feb 15, 2021

bors bot deleted the nrf-serialization-2.0 branch February 15, 2021 07:08

lschuermann mentioned this pull request Mar 22, 2021

Tock 2.0 Alpha1 #2446

Merged

18 tasks

Uh oh!

Port NRF Serialization to 2.0 #2393

Port NRF Serialization to 2.0 #2393

Uh oh!

Conversation

ppannuto commented Jan 29, 2021 • edited by phil-levis Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Pull Request Overview

Testing Strategy

TODO or Help Wanted

Documentation Updated

Formatting

Uh oh!

phil-levis left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

phil-levis commented Feb 9, 2021

Uh oh!

phil-levis commented Feb 10, 2021

Uh oh!

phil-levis left a comment

Choose a reason for hiding this comment

Uh oh!

phil-levis left a comment

Choose a reason for hiding this comment

Uh oh!

bradjc commented Feb 12, 2021

Uh oh!

hudson-ayers left a comment

Choose a reason for hiding this comment

Uh oh!

ppannuto left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ppannuto Feb 12, 2021

Choose a reason for hiding this comment

Uh oh!

phil-levis Feb 14, 2021

Choose a reason for hiding this comment

Uh oh!

phil-levis commented Feb 14, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

alevy commented Feb 15, 2021

Uh oh!

phil-levis commented Feb 15, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

phil-levis commented Feb 15, 2021

Uh oh!

bors bot commented Feb 15, 2021

Uh oh!

Uh oh!

ppannuto commented Jan 29, 2021 •

edited by phil-levis

Loading

phil-levis left a comment •

edited

Loading

phil-levis commented Feb 14, 2021 •

edited

Loading

phil-levis commented Feb 15, 2021 •

edited

Loading