ProcessStandard: Make debugging data optional #4188
Conversation
Needed for boards that use the sequential async process loader.
|
This generally looks like a positive change to me, though I think it might either need at least one example, or better documentation somewhere to guide people towards using |
Can use the `()` type for no debugging.
Only need the custom default for the map cell, not the inner type.
|
I added another sentence, but, this is somewhat hard to document. We don't have a board that doesn't use the debugging, and I'm not sure this is important enough to add one as an example. Unfortunately the type is passed through macros and is pretty disconnected from what it does. If you are thinking about this (and want to disable debugging) I think it is pretty straightforward to use, but if you are just reading the code it's not clear why a storage permissions policy needs a process debug type. |
|
@lschuermann I know we talked about this for a while. I don't remember anymore what the next step seemed to be, but this still seems like a step in the right direction to enable smaller RAM kernels. |
There was a problem hiding this comment.
Sorry for the delay in getting to this! This looks good.
I tried to go one step further than this and remove the various ProcessStandard specific debug hooks from the core kernel in favor of a more general abstraction. Unfortunately, doing this transformation meant that we'd either have a massive amount of dynamic dispatch or type parameters everywhere in the kernel. I want to revisit these efforts at some point in the future, but this is a step in the right direction.
I don't have any thoughts about the "discoverability" of this PR. I agree that having this be a somewhat un-/under-documented option is not great, but for anyone who's deep down the rabbit hole of optimizing Tock's size / performance, I hope this should be sufficiently apparent.
Pull Request Overview
Currently the
ProcessStandardstruct contains fields for debugging information. This leads to a tension: what is the right amount of debugging data to store? What if some kernels want to track more and others less? This attempts to shrink the size of theProcessStandardobject for kernels that may care about that.This PR makes the debugging information for
ProcessStandardonly accessible via a trait. Different kernels can use different implementations for that trait which may or may not store debugging information.By default we continue to use the full debugging information for any board that calls the
load_processesfunctions. Boards that use the async process loader can choose via the component which debug implementation they use.Testing Strategy
Compiling.
TODO or Help Wanted
n/a
Documentation Updated
/docs, or no updates are required.I added some more comments to process_standard.rs to give some context for what the
Dparameter is.Formatting
make prepush.