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

[Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx>]

Thanks, very nice read.

Few questions though:
- I guess the main difference between the Params.t and Cmdliner.Term.t is that 
the params are more "meta": they now how to print OCaml values and functions 
parsing OCaml values of that type (ie. that's useful in the context of Mirage 
multi-stage compilation, but maybe not so useful in a more generic case)
- Is that possible to build custom 'a converter? Missing an (`a option 
converter) and (int{32,64} converter), etc...

I am not very fond of the default references, not sure why you want someone to 
change them globally.

Also, how does it work when you want to define your custom parameters in 
config.ml? I think that was Magnus wanted to get his runtime extra value.

Thomas

> On 4 Dec 2014, at 14:41, Nicolas Ojeda Bar <no263@xxxxxxxxxxxxxxx> wrote:
> 
> 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