Internals of Feature API
Feature API

## Topics

| Internal Cryptographic Backend
| Policy instantiation module
| Policy calculation module
| Policy callback functions.
| Policy execution functions.
| Policy utilitiy module
| Helper functions module
| Utility module
| Basic IO module
| Key store module
| Policy store module
| Configuration utilities.
| Event log utilities.
| Profile module
| FAPI object serialization module
| FAPI object deserialization module
| Vendor specific module

## Detailed Description

This module holds internal APIs of the FAPI implementation.

Async programming style:

The tss2-fapi implementation uses an asynchronous programming style internally. This means that whenever a piece of code performs a potentially blocking operation it will instead return TSS2_FAPI_RC_TRY_AGAIN (similarly to ESAPI). Then this function is called again once the Poll returns ok. In order to carry the state of execution information over between the different invocation of the same function, the current state is stored in a state variable and all variables are stored in some kind of context variables. On the next entry to the function the state is evaluated using a swtich() statement and execution is resumed.

In order to understand the functional flow of code in FAPI, one can read the functions continuously over all fallthrough; and statecase(); statements. The statecase statements are the re-entry points of each function. The return_try_again() and FAPI_SYNC() statements are the preempt statements.