Open gparmer opened 6 years ago
To codify this, and make it a little bit more transparent, see the loader
branch.
mkimg
toml
specification and parsermkimg
processing with the build system via make component
(see below)llbooter
@
init args that go to a different componentmkimg
directory to create the new image guided by the system specificationbuild
directory to store the temporary component executables to populate the tar file, and hold the elf files to be interpretedThe build system is being changed to do compilation and some linking at normal compile time (make
), and to move the final linking stage (including the generation of the executable) to the mkimg
phase.
To understand why, see Option 2 in #352 for an overview of the highest-level goal of allowing different variants of interfaces.
Also see #364 to understand how this will also be used to help guide the library compilation and linking.
make
directive (component
) to enable a specific component to be linked, and pass in as make
variables all of the characteristics of that that component (name, target, interface and library dependencies).__cosrt_*
prefix and update the build system to link them all in when the component is created
Summary
I need to get some ideas onto "paper", and might as well do it in a location where other people can comment. This expands on Option 2 from #352 .
High-level idea: Interfaces should be polymorphic across different server implementations (#352), and the runscript should guide the entire process. Interfaces will expose a fixed functional prototype (in their .h file), but the stubs that implement the glue between components can differ. Additionally, in some cases, there will be no "server" component, and the stubs themselves will be library implementations of the interface. In this case, the interfaces effectively organize our equivalent of DLLs. It follows that many different libraries should be pushed from the
lib/
directory into an interface implementation (except for those that are included into every component).Some preliminaries:
compspecs
for short).Compilation and build life-cycle V2
The build system will be broken into the following stages (changes within this proposal are denoted with New):
Interface compilation
interface/<ifname>/{*.c, *.h}
)stubs/
subdirectories.DEPENDENCIES
support to the interfaceMakefile
specifications, to support using other interfaces. At this point, simply-I
the relevant prototype code and load the shared libraries, but don't follow through with using any specific interface stubs.Component compilation
.h
files to understand shared prototypes and structures.a
library of all of the interface's helper functions (ininterface/<ifname>/{*.h, *.c}
)include/
andlib/
files (as the current build system does).Composite Specification-driven, whole-system linking
@sched
component's initialization")__cos_ucap_*
capabilities exist, as do the__cos_sstub_*
and__cos_cstub_*
symbols all exist in each component and there should be no unresolved symbols.Image Generation
At this point, we have a collection of components that are fully linked into ELF programs, and we know the address of the user-level capability structures, and the server and client stubs, and which components depend on which other components.
Limitations and Warts
struct example {...};
version across all variants), or abstract (i.e. using onlystruct example;
and pointers). This will cause troubles if we want an interface that abstracts across thecapmgr
and thecos_kernel_api
as the latter wants a concrete representation that is allocated by the client.compspec
must resolve all dependencies, including those created by inter-interface dependencies. In the longer term, the only way I can see to resolve this is with strong "composition errors" with suggestions for how to resolve this.A
also depends on a component exporting interfaceA
. I believe this are somewhat trivial, so I'm leaving them till later.Future
compspecs
. We want to have acompspec
be able to export an interface that can be depended on by othercompspecs
. In other words,compspecs
should be treated as a component to remove replication in "system-level" collections of components.compspec
.Conclusions
This infrastructure will allow a level of polymorphism for the interfaces with an integration of libraries that will allow us to avoid a lot of the
cos_kernel_api
vscapmgr
mess that we have now. It will enable the composition specifications quite a bit of power to pull information out of the objects, and to add information in that will, long-term, enable us to pass information where we need it in a much simpler manner. The cost is in the development of the new booter, composition specification interpreter, and build system changes. This seems like a good trade-off. I believe I've addressed most of the annoying edge-cases, but if I've missed something, please let me know now!@Others @phanikishoreg @ryuxin @hungry-foolish