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

[Nicolas Ojeda Bar <no263@xxxxxxxxxxxxxxx>]

Hi list,

Thanks for the comments so far.  For greater clarity and precision, I wrote a
short document explaining the rationale and the design of the proposed
changes to the
`mirage configure` tool.

https://gist.github.com/nojb/f9c262d5fd691e6171ca

Any comments appreciated!

Best wishes,
Nicolas


On Tue, Dec 2, 2014 at 4:58 PM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> 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