-
Notifications
You must be signed in to change notification settings - Fork 747
Add ProcessInfo
capsule that allows userspace to inspect and control processes
#4411
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.
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
Conversation
pub struct Capability; | ||
unsafe impl capabilities::ProcessManagementCapability for Capability {} |
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.
This came up as a concern on the core call today.
While the decision to require a capability makes sense to highlight this as an "unsafe for untrusted userspace" capsule, creating the capability in the component hides this concern from board authors. Authoring or reviewing a board, it would be easy to miss this.
@alevy Brought up that probably components shouldn't create capabilities as a general rule. In practice, at the moment, they almost-exclusively create MemoryAllocationCapability
s. Excepting the sequential process loader, every other creation of ProcessManagementCapability
is done in the top-level board file.
For this PR, the only thing to change would be lifting the ProcessManagementCapability
out of the component here and taking a reference (e.g., still creating MemoryAllocationCapability
"like every other component" is fine).
I will open a separate issue for the more general question of capability creation in components.
} | ||
} | ||
|
||
pub struct Capability; |
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.
I noticed something while looking at the Rust compiler recently. They include a private field into structs such that they cannot be (safely) constructed from outside the current crate:
https://doc.rust-lang.org/beta/nightly-rustc/rustc_span/struct.ErrorGuaranteed.html
This seems desirable and important for the safety of Tock's capabilities as well. If they're public types, then anyone can name them, and we must prevent them from being constructed without the use of an unsafe constructor.
I'll check our other uses of capabilities whether that's a problem we have across the Tock kernel.
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.
Looks good other than the couple comments and the discussion around capabilities.
This allows userspace to list which processes are active.
Also change the command num to 6, return the app name length, and better handled a too-short allow buffer.
8a51f5a
to
a288387
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.
Aside from a, basically, unrelated issue about where capabilities can/should be instantiated, this looks good to me.
@lschuermann @ppannuto satisfied? |
Pull Request Overview
This capsule is used for the dynamic process loading tutorial by allowing users to list the processes on a screen and start/stop/inspect the processes.
Testing Strategy
There is a libtock-c implementation that uses this capsule.
TODO or Help Wanted
n/a
Documentation Updated
/docs
, or no updates are required.Formatting
make prepush
.