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

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 2 Dec 2014, at 16:52, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>> 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)

An addendum to this is that we don't want to always make every device use lazy 
and shared by default.

In the example above, it is perfectly sensible to want to have one IP stack for 
the purposes of DNS resolution only, and another for the purposes of opening 
network connections for data transfer.  That's difficult to setup on most 
systems today, but should be possible to assemble with Mirage.

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