Re: Formulating a newbies overview of how applications are packaged for use in rump kerrnels

  • From: Antti Kantee <pooka@xxxxxx>
  • To: rumpkernel-users@xxxxxxxxxxxxx
  • Date: Fri, 19 Jun 2015 01:20:40 +0000

On 19/06/15 00:13, Andrew Stuart wrote:

Can I ask please put forward my understanding of the mental model of how
applications get packaged into running rump kernels? Perhaps where my
understanding is wrong people might suggest what is correct? Possibly this
might form guide for newbs on the wiki.

Great idea!

** 2 command line arguments to application binary <- this is defined in
hardcodedjson/parameters to rumprun

hardcodedjson shouldn't be mentioned anywhere near user docs. It's just a hack to help with platform bringup before there's some more dynamic way to pass the config file on that platform.

** 3 shared libraries needed by application binary <- I’m foggy about this.
Where do they come from? How do they get into the kernel? Does rumprun know that
they are needed as part of it’s job, and include them in the kernel?
https://en.wikipedia.org/wiki/Library_(computing)#Shared_libraries

There is no support for shared libraries. If you think about it, it's rather pointless to have shared libraries in a unikernel.

###################################################################################
### So, the process for example to make Python work in rump would be:
###################################################################################

To clarify, this is *not* the case of what Antti is tackling just at the
moment, which is running a Cython application, i.e. Python converted to C, not
the same thing as an ordinary Python application.

How is it fundamentally different? In that the code won't be "builtin" to the executable, but supplied separately? (I'm not a python ecosystem expert or even a knowledgeable user)

First thing for the packager to understand is that parameters that are passed
to rumprun can also be put into a JSON data structure and hardcoded into
callmain.c. This will be changed in future to be more convenient, but it’s
important to understand that when these instructions talk about parameters to
rumprun, you can achieve the same by putting them into hardcoded json. It is
also useful to know that if you put parameters to rumprun, then rumprun has
options to dump out those parameters as JSON which can then be used in
hardcodedjson (after slashing quotes).

See above about hardcodedjson

2 command line arguments to application binary
ACTION: packager must add these to hardcodedjson in callmain.c
EXAMPLE: for Python, the name of the python program to be run, plus PYTHONHOME
or PYTHONROOT might be passed as cammand line parameters for example.

No, packager must use rumprun.
(Not sure why it's the packager's responsibility to choose the command line arguments!)

3 shared libraries needed by application binary
ACTION: I don’t understand if the packager needs to do anything here. How do
the shared libraries land in the right places?

No shared libraries.

4 environment variables
ACTION: packager adds these to hardcodedjson in callmain.c.
EXAMPLE: for Python, set PYTHONHOME to location of the standard Python
libraries and whatever other env vars Python needs to find everything.

Hmm, maybe we should allow for some "system" parameters to rumprun, e.g. "-s system.conf". system.conf could contain all the non-user bits for that particular unikernel.

Needs thought.

Thoughts, corrections, clarifications?

Not sure where the taxonomy of files is coming from. Why not just "system files" and "user files"?

Other related posts:

  1. Home
  2. rumpkernel-users
  3. Archive
  4. 06-2015