Attention is currently required from: Aaron Durbin, Furquan Shaikh, Marshall Dawson, Angel Pons, Julius Werner, Eric Peers. Hello build bot (Jenkins), Aaron Durbin, Martin Roth, Furquan Shaikh, Marshall Dawson, Julius Werner, Angel Pons, Eric Peers,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/56047
to look at the new patch set (#2).
Change subject: commonlib/bsd/future: Introduce future API ......................................................................
commonlib/bsd/future: Introduce future API
This CL introduces a futures API. It allows modeling asynchronous operations. This will make it possible to model DMA transfers, I2C transactions, EC operations, etc.
It was loosely modeled off the Rust Futures API: https://rust-lang.github.io/async-book/02_execution/02_future.html
Since we don't use interrupts while booting, the only option we have is to poll. For this reason I omitted the `wake` callback since there is nothing to call it.
I evaluated the existing threads.h API and it has the following down sides: * Each thread requires its own stack. This means that there is a pretty low limit to the number of concurrent async operations, and a lot of overhead. * There are no thread synchronization primitives (e.g., thread handles, join, etc), so it's difficult to wait for an asynchronous operation to complete. * It currently only works in ramstage. * It requires code to be reentrant since we can now have multiple threads of executing going through the same code. This will require adding support for mutexes to make sure critical sections are protected. Auditing this is complicated and error prone. * It makes it hard to tell from looking at the code if something is running in a different thread. * Timestamp tracking becomes difficult because we can context switch to a task that hogs the CPU for a while.
The futures API has the following advantages: * We can easily scale the number of async operations since each operation only needs to store the context to run its state machine. * It provides a synchronization primitive so it's possible to block until the operation is complete. * It works in all stages. * There is no need for mutexes since there is only 1 stack and thread of execution. * Async operations are explicitly modeled so it's clear if the code is asynchronous. * The busy_loop parameter allows putting off CPU intensive operations until they are required. This will allow for proper timestamp accounting. * Creating futures that depend on other futures is pretty simple.
BUG=b:179699789 TEST=Implemented the API for rdev and cbfs, it seems pretty ergonomic
Signed-off-by: Raul E Rangel rrangel@chromium.org Change-Id: I125a946233f122c2848704296efbcb3ca3c96079 --- A src/commonlib/bsd/include/commonlib/bsd/future.h 1 file changed, 86 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/47/56047/2