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

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

> On 1 Dec 2014, at 14:31, Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx> wrote:
> 
> 
> 
> Le lundi, 1 dÃcembre 2014 Ã 15:05, Thomas Gazagnaire a Ãcrit :
> 
>>> One can of course, make the names unique by combining the name of the
>>> parameter with the name of the CONFIGURABLE (currently
>>> semi-algorithmically generated to keep them unique), but this does not
>>> seem very user friendly.
>> 
>> Maybe expose a ?name paramater to all the combinators which will be prefixed 
>> to parameter arguments if needed.
> 
> I'm not sure that's the problem. If I understood well it seems that functor 
> application does generate new configuration values.  
> 
> Of course if they are meant to be shared among instances it means that you 
> are declaring them at the wrong place. Best would be to define a module with 
> "standard" configuration keys (e.g. ip address) to be used to be used 
> throughout the system and telling users to first try to use the standard 
> configuration keys before trying to define new ones.

One problem currently is that while functor application generates new 
configuration values, the actual instantiations of devices may reuse the 
functor application with different state variables.

For instance, right now if we generate a HTTP client, we need this in our 
config.ml:

let sv4 = stack default_console in
let res_dns = resolver_dns sv4 in
let conduit = conduit_direct sv4 in

The stack (sv4) is instantiated as one functor, but is currently connect()'ed 
twice.  The observable bug is that it issues a DHCP query for every time it is 
called.

Filling this at first glance requires instantiations to be lazy, so that we 
reuse them.  However, it may be necessary to explicitly name devices so that we 
can safely memoise multiple stacks that share the same functor but otherwise 
differ in their state (e.g. two completely separate stacks that issue their own 
DHCP requests with their own MAC addresses, but otherwise share the same OCaml 
TCP/IP functors).

(see https://github.com/mirage/mirage/issues/331 for more)

> 
> Now the question and problem remains whether there would be the need for per 
> module instanciation configuration keys. In that case it seems that what 
> Thomas is proposing is the good answer, the module parameter should then 
> provide a `val name : string` in the signature that you thread in the 
> resulting module using that `?name` parameter when it creates its own keys.

This is probably useful to generate nicer error messages as well, but we have 
to be very careful that the ?name parameter not introduce module name clashes 
in the generated code.  Right now they're guaranteed to be fresh module names 
since they're generated inside the mirage tool.

> P.S. It would be nice to provide more specific links when you ask for 
> feedback, of interest here would be the API and the way it gets used in the 
> code.

I did indeed try to take a look at the patch right now using the `compare` 
button on that branch, and ran right into Nicolas' IPv6 patches there as well.  
This is probably a hint to me that they need review and merging soon :-)

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