Hi Nikhil, On Monday, 11.06.2018 at 10:15, nikhil ap wrote: > > The issue is not so much working out what the guest-side API (i.e. that in > > solo5.h) should be, but keeping the conceptual integrity of how Solo5 > > (kernel/bindings), ukvm (monitor/tender) and application (unikernel) fit > > together. This will require a digression into the project's history, so > > please bear with me. > > > When you say binding, do you mean the current hypercall interface?
Based on the terminology discussed in #172 (ukvm renaming), the "bindings" are the implementation of the Solo5 public API for a particular target. "Target" in this case refers to a host/hypervisor/tender combination. In terms of code organisation, bindings are what we have today in kernel/. This should all be much clearer after the renaming and reorganisation is done, hence the need for that to happen sooner rather than later. > > My preferred approach (discussed with Dan & Ricardo several times, but not > > in public) would be to replace the current model of build-time coupling > > with run-time coupling. The main points of a "back of the napkin" > > implementation would be something like this: > > > > 3.1. The application binary, supplied by the "user", would contain a > > "manifest" (e.g. inside a special ELF note) declaring which resources > > (NICs, block storage, future IPC, etc.) it requires to operate. > > > > How should the user add this manifest? Do we need to use the toolchain to > create such a binary? > For example, do we use objcopy to add the elf note? May be using an example > with Mirage or IncludeOS might > help me in understanding better. In the case of MirageOS, the "mirage" front-end tool already has all the information it needs to produce such a manifest. So, for MirageOS the relevant build-time commands (using objcopy, or generating a .c/.S which produces the relevant special section, to be determined) would be generated at "mirage configure" time, and then executed at "mirage build" time. I'm not familiar with IncludeOS' build system, but I presume a similar mechanism can be implemented there. > Also, what is the advantage of using the manifest inside the binary instead > of using a configuration file such as > json to specify the resources? We could read the configuration file, which > would include all the information you mentioned > in a manifest and could generate a tender which is crafted for the > application. Wouldn't this satisfy the 2 points above? If we split the manifest and associated artefact, then this has several disadvantages: 1) The user/operator now has to keep track of two files. Or we have to ship as a .tar/other container, in which case we may as well just embed the manifest in the ELF binary. 2) The coupling is much looser, so the potential for messing things up is accordingly higher. If we combine the two in a single artefact, with the associated build-time runes on the libOS side being generated by the build system (i.e. the developer does not create a manifest "manually") then these problems go away. By the way, you mentioned JSON. JSON is absolutely unsuitable for this purpose; given that the (untrusted) manifest needs to be interpreted by e.g. a (trusted) tender, the format needs to be designed in a way that > > 3.3. It follows that the tender can now be supplied separately by the > > "operator". At start-up, it would load the manifest and use it to determine > > which modules to enable [4], based on this list it would also require the > > "operator" to configure all host resources for all enabled modules. > > > > Does this mean all the modules need to be compiled and included in the > tender > even though the application might not load it? > I'm assuming by loading you mean by adding it to the module table which we > have now in tender. Well, I've not thought through the implementation in full yet. "Loading" might mean dynamic linking, or something else. Or, in an initial implementation it might mean what you write (all modules are compiled in, unused ones get disabled). If we get the design right then the implementation can evolve. > I would like to understand the scope of your design before proceeding. > May be I can build a minimal prototype which affirms to the > tender/unikernel requirement we have and *then* > can look at supporting multiple NICs. (Although I do a gross hack for > supporting multiple nics already > but I don't think its going to be useful considering what is required) Sure, I can try and write down more of the design, but need to get releasing and renaming out of the way first, otherwise we're going to keep getting confused about the terminology. -mato
