Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Create a libtock-platform crate including syscalls + async traits. #217

Closed
jrvanwhy opened this issue Jul 7, 2020 · 1 comment
Closed

Create a libtock-platform crate including syscalls + async traits. #217

jrvanwhy opened this issue Jul 7, 2020 · 1 comment
Assignees
@jrvanwhy
Labels
in progress

Comments

@jrvanwhy
Copy link
Collaborator

jrvanwhy commented Jul 7, 2020

I am splitting PR #211 into multiple pieces. This issue is to document, discuss, and track those refactoring efforts.

As a high-level overview, I would ilke to do the following:

  1. Split up the functionality of libtock-core into multiple crates that live in the core/ directory. libtock-core would remain as a crate that aggregates all the functionality, so that applications only need to use one crate directly. Examples and integration tests would live in core/examples and core/tests, so they can depend on libtock-core's cumulative functionality.
  2. Allow for unit tests for each sub-crate that run on the host system. For example, the libtock-platform crate should have unit tests that run on the host system via a trivial cargo test. These tests are easier and faster to run that on-device tests, and can be run under cargo miri for undefined behavior detection. This is the idea discussed at [RFC] Reorganize libtock-rs for testability #132 (comment)
  3. Solve the soundness issues with the syscall API/platform layer (previously discussed in allow() is unsound #129 and Subscriptions and shared memory have a loophole which can lead to UB #143).

In particular, I intend to create a libtock-platform crate that contains the following:

  1. A trait (Syscalls) representing raw system calls. There is no implementation of this trait in libtock-platform, as libtock-platform is OS-independent. Instead, separate crates (probably libtock-runtime and a testing crate) will provide implementations of Syscalls.
  2. A Platform struct that provides a higher-level interface over the Syscalls trait, supporting an asynchronous execution model similar to that used by the Tock kernel. Platform is not implemented yet. Its API is presented in the form of the PlatformApi trait, which is currently partially written, so that other libtock-core components can easily be generic over the platform type.
  3. ErrorCode and ReturnCode types that form efficient abstractions around the kernel's ReturnCode type.
  4. Traits based on the prototyping I documented at https://github.com/tock/design-explorations/tree/master/zst_pointer_async for asynchronous APIs: StaticCallback, AsyncCall, and Callback. These should allow for libtock-core to provide a generic adapter for synchronous APIs and a futures-based adapter for synchronous APIs, plus prevent a recursion issue the Tock kernel has experienced.

In future work, I will implement libtock-runtime, which will provide the real Syscalls implementation and entry point for libtock-core. I will probably pull the panic_handler, start implementation, and allocator into separate crates so that applications can switch between them. libtock-core will pull in everything by default for clients that want the convenience.
@jrvanwhy jrvanwhy self-assigned this Jul 7, 2020
jrvanwhy added a commit to jrvanwhy/libtock-rs that referenced this issue Jul 8, 2020
@jrvanwhy
Add the libtock_platform crate.
3f1d24e 
Currently, the crate is just a skeleton. I will add functionality in future PRs (I am merging an empty crate so that I can send PRs in parallel in the future).

I will be replacing the system call layer in libtock_core::syscalls with a new layer in libtock_platform. libtock_core depends on libtock_platform and will re-export its functionality. This work is tracked at tock#217
jrvanwhy added a commit to jrvanwhy/libtock-rs that referenced this issue Jul 10, 2020
@jrvanwhy
Add the libtock_platform crate.
988305c 
Currently, the crate is just a skeleton. I will add functionality in future PRs (I am merging an empty crate so that I can send PRs in parallel in the future).

I will be replacing the system call layer in libtock_core::syscalls with a new layer in libtock_platform. libtock_core depends on libtock_platform and will re-export its functionality. This work is tracked at tock#217
@jrvanwhy jrvanwhy mentioned this issue Jul 10, 2020
Merged
bors bot added a commit that referenced this issue Jul 17, 2020
@bors @jrvanwhy
Merge #220
957738d 
220: Add the `libtock_platform` crate. r=bradjc a=jrvanwhy

Currently, the crate is just a skeleton. I will add functionality in future PRs (I am merging an empty crate so that I can send PRs in parallel in the future).

I will be replacing the system call layer in libtock_core::syscalls with a new layer in libtock_platform. libtock_core depends on libtock_platform and will re-export its functionality. This work is tracked at #217

Co-authored-by: Johnathan Van Why <jrvanwhy@google.com>
This was referenced Sep 23, 2020
Closed
Closed
@jrvanwhy
Copy link
Collaborator Author

jrvanwhy commented Feb 9, 2022

libtock_platform and the other crates this issue describes have existed for a long time, and are currently ready for use.

@jrvanwhy jrvanwhy closed this as completed Feb 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jrvanwhy jrvanwhy

Labels
in progress
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@jrvanwhy