Library indirection: Design and Implementation #15
Description
- Decide how this should be done (probably some discussion needed)
- Update the ALLVMFormat documentation
- Update liball
Related concerns/thoughts/ideas:
- Can we "expand" an allexe containing multiple bitcode files into the indirect reference representation? What about an allexe that's already been processed by alltogether?
- Opportunity for deduplication is a big reason to do this at all-- how should this work?
- How can we leverage this indirection while generating allexe's in the first place?
From last week's ALLVM meeting, as written up by @yotann (thanks!):
Next topic: indirect references to libraries. If we make an ALLVM OS, it won't work well to have redundant copies of each library in each .allexe that uses it; the libraries will have to go in separate files which are referenced by the .allexes. But that means the .allexes will no longer be self-contained units, or useful units of data at all; you can no longer share or delete a single .allexe file and expect everything to work correctly. The .allexes will have to be stored along with their libraries in some sort of repository, which could be as simple as a directory containing lots of .allexe files. Liball will hide the details, so it will be possible to support multiple kinds of repository.