- Haven't found how to cut-off hardware layer. Virtio lead didn't help.
- Osv builds very tricky libraries. Impossible to use as is at host.
- Bottom-up approach seems reasonable for now
Just collecting information about unikernels/kvm and friends. Little osv source code digging with no actual result. Discussions.
Find shared libraries that OSv builds. Found libosv.so which has lots of symbols, but null .text section. Looking to loader.elf. Tried to compile-and-run with empty app with no success. libosv.so defines custom entry point (start32) which fails at lgdt instruction. Switched to custom loader.so with all symbols but without custom entry points. Fail at compilation this shared object.
It seems unproductive. Top-down approach with no strong domain knowledge/experience is very ineffective for me. Will try switch to bottom-up approach tomorrow (take signals and thread implementation from OSv) if Yaroslav won't do it by himself or continue trying to run something from OSv.
Tried to compile different libs from osv, also tried to dlopen them from an external application. No success yet. It fails on calling any function. I.e. dlopen and dlsym pass, but that's all. Btw, only libosv.so could be dlopen'd. Others shared objects can't.
Switched to cutting some sort of libc.so from OSv project.
TODO: investigate segfaul with dlopen in asm.
Switched to compiling standalone libc.so from OSv project. Main problem i faced is assembler code which isn't supposed to be relocatable. It's understandable. In one-process world you don't have to worry about PIC code. All available memory is yours. Only one application is loaded. With custom loader.
Rewriting code to make it relocatable is quite tricky. It could't be automated. Every case is unique and takes time. For now, i've rewritten following files:
- sigsetjmp.S
- getcontext.S
- setcontext.S
TODO: continue with start_context.S
Written with StackEdit.