On Sat, Jun 11, 2016 at 9:17 PM, Antti Kantee <[email protected]> wrote: > On 11/06/16 15:22, Neeraj Sharma wrote: >> >> Hi, >> >> I was toying with the idea of using shared objects which could be >> loaded later (lazy loading) within application within the Rumprun >> unikernel. Is this even possible? Additionally, is Rumprun unikernel >> designed against that scenario or the philosophy of code execution? > > > First of all, when you talk about shared objects, do you actually mean > shared objects (shared with what?), or are you just using that term to mean > loadable objects? >
Huh! I meant dynamically loadable objects. I've been drinking the generic-os-kool-aid for too long I guess. > Next, I'll assume you mean "C" objects, and not e.g. some quasi-interpreted > programming language objects, where the runtime supports loading on its own. > Yes. C/C++, but in this particular case C. > Rumprun supports loading *kernel* objects -- standard rump kernel feature -- > or at least can be made to support that with relative easy (need to pass and > load the symbol table). However, loading code requires a linker, and there > is no generic linker in the stack. Ok, loading code doesn't require a > linker, but making the loaded code useful requires a linker ;) > > Generically speaking, it's impossible to say what the best option is. > Without knowing more about your use case, I'd say it's against the > philosophy. > There were a couple of reasons to think about it and rather than digressing at start let me pick the first one. In Erlang there is a concept of Native Implemented Functions (NIFs). As with other programming languages a support for native compilation via C is available via dynamically loadable objects. I believe that an argument can be placed to re-design the whole plugin concept for Rumprun unikernel but that would be too intrusive and needless to say a lot more work. Therefore I find is better to let Rumprun unikernel take care of this scenario with minimal changes to Erlang NIF design philosophy and yet get it to work. -Neeraj
