Re: [MirageOS-devel] command line arguments for unikernels

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 28 Nov 2014, at 16:15, Nicolas Ojeda Bar <no263@xxxxxxxxxxxxxxx> wrote:
>>>>>>> 
>>>>>>> There is documentation near the top of `mirage.mli` (see below for
>>>>>>> which branch) that you can read to try to make sense of the design.
>>>>>>> 
>>>>>>> How to use it:
>>>>>>> 
>>>>>>> There is a new type, 'a Mirage.Param.t, which represents a parameter
>>>>>>> (given at compile-time, run-time or hard-coded) of type 'a. There is
>>>>>>> no way to retrieve the contents of a value of this type because the
>>>>>>> contents may not be available until run-time.  What this type does is
>>>>>>> to generate code in `main.ml` representing values given at
>>>>>>> compile-time or generate code to extract the values from the kernel
>>>>>>> parameters passed at run-time (in the 'extra' field of .xl file for
>>>>>>> xen, in the command line for unix).
>>>>>>> 
>>>>>>> The combinators in Mirage need to be modified slightly to take 'a
>>>>>>> Param.t's instead of values of type 'a.  This is a small change in
>>>>>>> general.

I can't quite follow the whole thread quoted above, but the approach I was
suggesting during a recent call seems relevant: 

From http://openmirage.org/wiki/weekly-2014-11-12:

>  Library request! ThomasG and Anil have built ez versions of Daniel Bunzli's 
> libs, such as ezxmlm andezjsonm, which are less flexible but provide more 
> convenient functions. They'd like to have an ezcmdliner, which takes notions 
> of terms and does unix.get-env. It would let them replace adhoc environment 
> parsing in configuration and let them assemble an environment. One of the 
> interpretations would be a dialog-based interface and could do bash-shell 
> completion. This way, mirage configure can drop you into a UI to select the 
> things you wanted. It should be a simple library and only a couple of days 
> work as it's just a front end to cmdliner itself. After some discussion, it 
> seems that Dave might have pieces of this so he'll dig it out and have a look 
> but others are very welcome to dive in.

The idea is to provide a layer above cmdliner that declaratively specifies
the set of command-line inputs you need.  This would then be interpreted by
various backends to provide:

- a unix command line that looks up Terms from getenv, a config file or command 
line option
- a xen equivalent that would use xenstore.
- javascript could similarly be parameterised via an interactive ui
- support more exotic interpretations such as bash/zsh command line completion 
and using the `dialog` shell tool to show textual dialogs (as Debian or FreeBSD 
do with package selection)

One key design decision is how to represent the various Terms.  Cmdliner is 
currently a flat list of options, but it's often much more natural to represent 
configuration as a tree of values instead.

I'm not sure how to resolve this aspect of things.  It would be easy to build 
the config terms as a tree, and then map those onto the relevant backends:

- a filesystem mapping instead of a config file (e.g. a directory hierarchy 
where you just create small files and values)
- xenstore is already a tree
- for the command-line, you'd need to flatten these, perhaps into subcommand 
groupings (which cmdliner already supports).

Note that OS.Env in mirage-platform already gives a string configuration 
variable. (from argv for unix, and from start_info for xenstore).

-anil


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel