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

[Nicolas Ojeda Bar <no263@xxxxxxxxxxxxxxx>]

On Thu, Dec 4, 2014 at 3:02 PM, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:
> 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)

Yes, the main difference is that the `'a converter` type of `Param`
needs to do more.  Other than that one could almost replace a `'a
Param.t` with a `'a Cmdliner.Term.t`.

> - Is that possible to build custom 'a converter? Missing an (`a option 
> converter) and (int{32,64} converter), etc...

Yes, of course.  I forgot to include that.

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

Agreed.

> 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.

This would involve adding a function `add_to_params` similar to
`add_to_opam_packages` and `add_to_ocamlfind_libraries` to signal that
some extra params
are used by the unikernel.  Moreover a mechanism is needed to access
the value of those parameters from inside the unikernel code, but I
haven't figured this out
yet.

Thanks for the comments!

Best wishes,
Nicolas

> 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