Hi Nikhil, On Monday, 11.06.2018 at 16:10, nikhil ap wrote: > 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.
That's correct. > 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? Yes, obviously the goal would be to have easy to use tooling available to assist the various guest unikernel build systems to generate the manifest. Integrating it into the final unikernel binary should just be a case of passing the resulting object to 'ld'. > > 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. I'm not sure what you mean. What selection of modules gets complied in/enabled for a tender would be up to the operator of that tender to determine as a policy decision. The tender would then, based on interpreting the binary's manifest, determine whether or not it "can/will/is allowed to" launch the (separately supplied) unikernel. > > 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 :) ...that allows for secure deserialization of untrusted data? See here for an (old) comparison of some formats: https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-sbe.html Personally I'm very much in favour of minimalism, so there's also the possibility of just inventing a custom binary format tailored to only the information we need to store in the manifest. I don't yet know which approach is best in the long term. Note that we should be able to version the manifest as a whole, so we could start with a simple custom format and move to something more involved later if there is a need. > > 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. No, the manifest is part of the change to a run-time coupling with a tender. I.e. the IncludeOS build system only has to produce a unikernel with a manifest, not a tender binary. Those would be supplied separately by downloading and building the "new" Solo5. -mato
