On Sat, Jun 11, 2016 at 10:03 PM, Antti Kantee <[email protected]> wrote: > On 11/06/16 15:56, Neeraj Sharma wrote: >> >> 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. > > > I don't quite follow why dynamically loading something is necessary. Why > can't you link the objects into the binary before you run it? >
The design of dynamically loading is to enable clean design and not force user to recompile the Erlang VM for their custom NIFs (or C code). It can be argued that for Rumprun this design be broken, but that will be too intrusive to the base design. I am in the process of understanding and brainstorming if at all this could be done in the least intrusive way, but having said that I want to go down the path of dynamic loadable objects within the Rumprun unikernel as well. -Neeraj
