Hi Martin,
On Mon, Jun 11, 2018 at 2:48 PM, Martin Lucina <mar...@lucina.net> wrote:
> 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.
I'm not familiar with MirageOS. I need to look at how it works.
Although, this implies that we need to change the tooling for every
unikernel we support.
For ex, MirageOS, IncludeOS, Rumprun etc. Also, whenever we need to add
configuration parameters/resources
to the manifest, we would have to change this everywhere to reflect this.
Is it possible to have
some kind of stand-alone tool which the other unikernels can trigger during
the configuration time
to be able generate the binary with the manifest?
>
> > 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.
>
I guess an advantage of using a separate configuration file would be that
we
can compile only the module that is required.
>
> 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
>
.. a way that? Would like to know this ends :)
I thought of Json because IncludeOS uses json to configure the
resources and specify them to Qemu.
An example:
{
"image": "test_router.img",
"mem" : 320,
"net" : [{"device" : "virtio"},
{"device" : "virtio"}],
}
So in order for us to be able to support IncludeOS we would have to have
their
build system (cmake) parse the json file and emit a tender binary with the
manifest.
I am interested to know how rumprun specifies its resources. Currently they
have a multi-step process to generate a unikernel image using rumprun tool
but they do mention that it might go away and be replaced with json.
> > > 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.
>
> Of course.
> -mato
>
--
Regards,
Nikhil
