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

[Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx>]

>>>>>>>>> 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).
> 
> Another way to think about this aspect is as a MetaOCaml stage, where the 
> eventual value will not be known until a certain number of program stages 
> have been evaluated.
> 
> I wonder if we're going about this in reverse.  It may be better to code the 
> configuration structure in Metacaml as a prototype, and then work backwards 
> to see how this should be implemented in a more portable OCaml without full 
> support for staging.
> 
> This could also influence how we make this work in (e.g.) Assemblage...

Assemblage has exactly the same "functionality": it first pass the command-line 
to get some useful parameters (such as --include, which can help with dynamic 
linking of the config file), then compile the config and dynlink it, then 
extract a list of cmdliner terms and pass it to the command-line interpreter. 
So `assemblage --help` will display only the help for the features used in the 
config file. We had a quick chat with Nicolas and I think a similar solution 
would work well for the mirage tool as well.

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