Specialization of interface stub code loaded into client/server, based on server's specification

[Gabriel Parmer]

At the highest-level, this issue proposes a new design for how code associated with interfaces is integrated both with the client and server. First, the header file that shares the name of the interface should contain the functions that will be undefined within the client (with the sole exception of functions that are meant to be inlined into the client, which should be exceedingly rare). User-level indirection tables (like PLTs) will be generated to indirect calls to these through a set of function pointers that are -- by default -- set to point to the interface-specific stub code on the client side. On the server side, each invocation starts by activating the server stub function that first gets a stack, then executes interface-specific code which then calls the c function that implements the interface logic.

This issue answers the question: can we easily allow different server component implementations of the same interface stubs? We'd want to use different stubs in different situations because 1. data might be serialized differently, 2. the methods of invocation might change depending on situation (sinv vs. asnd/rcv), and 3. some implementations of the same API should significantly diverge (kernel API calls vs. capmgr calls).

There are two options, but both involve a fundamental change in the compilation that integrates runscript processing: Only when the runscript (thus full-system specification) is provided and executed, are components put through a final linking phase that attaches the client stubs specific to the components that are depended on. Both options have some similar organizational elements. The interface directory includes:

• .h file codifying the API
• .c files that are compiled into a library linked directly with the client
• stubs/ that includes .S and .c files that turn into the stubs (corresponding to the c_* and s_* files)

Option 1: multiple interface directories

An interface such as resmgr might have an implementation that goes through the capmgr, and another that uses cos_kernel_api directly. With this option, we might have resmgr/, resmgr_capmgr/, and resmgr_kern/. The .h file in resmgr/ used consistently across all implementations, but the stubs are used from the specified server's interface.

Bad. Clutters the interface directory. Makes asymmetry in the contents of different files in the interface directory. Increases confusion and misunderstanding.

Good. Very few changes to the actual build system, as is.

Option 2: multiple stubs in the same interface directory

Expand the stubs/ directory to optionally include a set of subdirectories that each contain different stub implementations. The normal stub directory will likely still contain the default implementation. For example, the resmgr/ interface might include stubs/, stubs/capmgr/ and stubs/kern/. Again, which stubs are actually used would be decided by the run-script.

Bad. More changes to the interface structure, and build system.

Good. A clearer mapping to the specialized stubs, while maintaining clarity of which files/code is associated with which interface.

---

I'm erring toward the second option.

Opinions? @phanikishoreg @Others @ryuxin @hungry-foolish