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.
################################################################################### ### General structure of how *nix applications typically map to the rump kernel model ################################################################################### Many *nix style applications have these general components, and this is how those components map into a rump kernel: ** 1 application binary <— this is what gets cross compiled using rumprun-XXX-cc. Getting this application to run is the goal of the overall process. ** 2 command line arguments to application binary <- this is defined in hardcodedjson/parameters to rumprun ** 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 ** 4 environment variables <- these can be passed as hardcodedjson/parameters to rumprun. ** 5 application configuration files <- these need to go into file storage which is mounted by the rump kernel. When the rump kernel boots up, it will automatically start the application binary. The application binary will find its configuration files probably from command line parameters, environment variables or its default expected locations. ** 6 application data files <- these need to go into file storage which is mounted by the rump kernel. In future its likely that file storage will be either a block device attached to the virtual machine, or a file system that somehow is baked in to the kernel. ** 7 additional files <- these need to go into file storage which is mounted by the rump kernel. ** 8 for languages such as Python or Ruby or whatever, the user’s Python application source code <- these need to go into file storage which is mounted by the rump kernel. ################################################################################### ### 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. Terminology: person doing the application packaging = “packager” 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). This may be obvious to some people but not to newbies: it is important to understand is that despite the fact that in the rumpkernel world you will probably do *everything* in Linux, applications are effectively running NOT under Linux but under NetBSD. That is why you need to cross compile application binaries, targeting NetBSD. rump kernel applications are effectively NetBSD applications, not Linux applications. So how to package up your application to run in a rump kernel? 1 application binary ACTION: packager must compile application using rumprun-XXX-cc and then rumpbake. EXAMPLE: for Python, this needs to be cross compiled 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. 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? 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. 5 application configuration files ACTION:packager needs to provide file storage and mount at the expected point. packager needs to set parameters or env vars to pick up the config files. 6 application data files ACTION: packager needs to provide file storage and mount at the expected point. packager needs to ensure application is configured to find those files. EXAMPLE: In the case of Python if your Python code uses files then make sure your code is using the correct directory located on one of the file systems that you have mounted. 7 additional files ACTION: packager needs to provide file storage and mount at the expected point. packager needs to ensure application is configured to find those files. EXAMPLE: In the case of Python, the standard library of Python modules and additionally installed Python modules. Define hardcodedjson/parameters to rumprun to set the required environment variables or command line parameters so that Python can find them i.e. PYTHONPATH PYTHONHOME PYTHONROOT. 8 for languages such as Python, the user’s Python application source code ACTION: packager needs to provide file storage and mount at the expected point. packager needs to put the application source code into a directory somewhere. EXAMPLE: In the case of Python you can put your source files anywhere on the file systems that you have mounted, and set environment variables pointing to your course file or pass source filename as a parameter to the command line defined in hardcodedjson/parameters to rumprun Thoughts, corrections, clarifications?
