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?
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.
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.
