Capability protocols. Protocols for managers and regular components

[gparmer]

Many researchers are converging on needing protocols for regular components, separate from manager components. This issue is an umbrella project that includes three broad aspects:

• TODO Normal components are not charged with managing the capability-based resources, instead focusing on providing functionalities and abstractions while harnessing the managers of the system via synchronous invocation. These are most system components, and they build the level of abstraction with each component. More information: see #252.
• Manager components are those that receive the capability layout. These are responsible for managing kernel resources explicitly via capabilities.
  • The cos_kernel_api, cos_defkernel_api, and sl (scheduling library) are libraries to make this management easier, but they often assume allocation-only resource management (i.e. for embedded systems, or constructor-based booters).
  • TODO The cos_sys API, based on parsec, will handle dynamic allocation and deallocation in a multi-core-aware manner. This will consider system quiescence as a fundamental resource management consideration.
• TODO We will want to be able to execute managers as normal resources in the future, which requires virtualization of the component layout for managers, while transparently invoking managers for actual resources. This was initially prototyped in the vkernel work, but needs a lot more work. For more details, see #253.

@phanikishoreg @ryuxin @hungry-foolish @RobertGiff @lab176 (forgot I could do this here!)

[gparmer]

There is likely more nuance to this break-down between the component protocols than I'm acknowledging here. Do we want schedulers to have to be full managers, or should we have a separate scheduler protocol?