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.
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 (
sinvvs.asnd/rcv), and 3. some implementations of the same API should significantly diverge (kernel API calls vs.capmgrcalls).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:
.hfile codifying the API.cfiles that are compiled into a library linked directly with the clientstubs/that includes.Sand.cfiles that turn into the stubs (corresponding to thec_*ands_*files)Option 1: multiple interface directories
An interface such as
resmgrmight have an implementation that goes through thecapmgr, and another that usescos_kernel_apidirectly. With this option, we might haveresmgr/,resmgr_capmgr/, andresmgr_kern/. The.hfile inresmgr/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, theresmgr/interface might includestubs/,stubs/capmgr/andstubs/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