Support for Zephyr kernel objects #5
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
d3zd3z
had a problem deploying
to
github-pages
GitHub Actions
Failure
d3zd3z
force-pushed
the
kobj
branch
2 times, most recently
from
1780b80 to
2400c74
Compare
ycsin
reviewed
Oct 9, 2024
|
any hints on build? I get below error |
Add a synchronizer for forks based on sending messages over channels to a worker thread. Signed-off-by: David Brown <[email protected]>
Rather than just printing a bunch of information out as the various philosopher threads dine, use some data protected within a Mutex to collect statistics, and print those out periodically. Signed-off-by: David Brown <[email protected]>
Although this function has constraints on how it can be used (the thread that calls unlock must also have called lock). However, according to the documentation, it detects this, and returns an error. As such, the wrapper in Rust does not need to be `unsafe` but can merely reflect that error code in the `Result` that it returns. Signed-off-by: David Brown <[email protected]>
Now that `sys::Mutex::unlock` has lost its `unsafe`, we don't need an unsafe block for it. Signed-off-by: David Brown <[email protected]>
This function returns initialized memory, and is therefore inherently unsafe. Added some commentary about how it is used safely. Signed-off-by: David Brown <[email protected]>
Move the Wrapped trait above the StaticKernelObject so that the traits are immediately declared after the type the apply to. Signed-off-by: David Brown <[email protected]>
Although these, in their current state, are safe to Clone, having these semantics will make it difficult for us to later add these types that are allocated from a pool. Uses that currently expect to clone can generally wrap these in an Arc, to allow for the sharing. Signed-off-by: David Brown <[email protected]>
|
Nothing new, just a rebase on top of the thread fix. |
The `Fixed` type encapsulates something that can either be a statically allocated object or a dynamically allocated one. It is conditional on `CONFIG_RUST_ALLOC`, and if that is not defined, will just end up represented as the underlying static pointer. Signed-off-by: David Brown <[email protected]>
Add support for dynamically allocated Semaphores. These can be freely allocated, but are not usable from userspace. Signed-off-by: David Brown <[email protected]>
Add a sample that implements the forks using dynamically allocate semaphores. Signed-off-by: David Brown <[email protected]>
Add support for dynamically allocated sys::Mutexes Signed-off-by: David Brown <[email protected]>
Switch to using dynamic Mutex types for this demo. Signed-off-by: David Brown <[email protected]>
Add support for dynamically allocate sys::Queues. Signed-off-by: David Brown <[email protected]>
Implement `unbounded` that is able to dynamically allocate the underlying Zephyr queue. This is useful in cases where none of the queue access happens from userspace. Signed-off-by: David Brown <[email protected]>
Use the new dynamically allocated Channels to simplify the code. Signed-off-by: David Brown <[email protected]>
Add dynamic allocation support to the sync Mutex and Condvar. When allocation is available, and userspace is not used, these can be used pretty much the same as those from std. Signed-off-by: David Brown <[email protected]>
Use the simpler `new` methods instead of static allocaiton. Signed-off-by: David Brown <[email protected]>
|
This push adds support for dynamically allocating most of the kernel objects. There are restrictions, mainly that the dynamically allocate objects can't be used from userspace, but this restriction is the same for C code on Zephyr. And, possibly obviously, the dynamically allocate objects require dynamic allocation to be enabled. |
|
Still looks reasonable to me. Sorry - I've been reviewing intermittently all morning getting distracted by the odd meeting. |
ithinuel
approved these changes
Oct 25, 2024
d3zd3z
force-pushed
the
kobj
branch
4 times, most recently
from
e7d869d to
aa1e082
Compare
Add -M full to the twister build so that it cleans up space as it goes. This should allow the build to run to completion. Add -j4 to the build. Although the CI images currently have 4 cpus, this will help protect us against future ones that have more. Give twister an explicit list of platforms. This fixes two issues. One is that the output is getting flooded with messages about skipped tests. The other is this allows us to add platforms that qemu seems to be ignoring entirely. Signed-off-by: David Brown <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a Rust abstraction around Zephy's kernel objects. This includes a mechanism to use statically declared kernel objects, as well as the possibility of dynamically allocated objects, managed as a pool for each type.
The initial kernel object supported is the
k_mutex, which is managed by the rust typesys::Mutex. This is a thin wrapper aroundk_mutex, and can be used for simple coordination. It, however, does not manage Send/Sync aspects that are handled bystd::sync::Mutex, which functionality will be provided in a later PR.Closes #16, Closes #17, Closes #18, Closes #19, Closes #20, Closes #21