Re: [MirageOS-devel] Remove DEVICE.connect?

[Thomas Leonard <talex5@xxxxxxxxx>]

On 26 January 2015 at 11:53, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> On 22 Jan 2015, at 14:02, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:
>>
>>>>>> So, I propose removing connect from the type signatures (but keeping
>>>>>> it in the implementations). Then, being given a device only implies
>>>>>> the ability to use it, not the ability to create more devices.
>>>>
>>>> Can you still easily compose devices together if you don't have a way to 
>>>> connect? Who will be responsible for calling the implementation-dependant 
>>>> connect function? Only the mirage tool in main.ml? (I guess that's already 
>>>> the case)
>>>
>>> Yes, code that wants to call connect (such as the generated main.ml)
>>> has to know the concrete module type. But this is already the case,
>>> because the "id" types are all abstract in V1_LWT.
>>
>> indeed, the mirage tool already has to deal with id of various types, so the 
>> changes you are proposing should be fine (and saner).
>>
>>> It will also mean we can use other signatures for connect (e.g.
>>> allowing multiple arguments or optional arguments) if needed.
>>
>> That's indeed a good argument. If we don't expose the connect fonction, we 
>> can use more complex function creators when needed - that's good (and we 
>> already kind of quite do that, for instance to init the http stack where we 
>> need to construct callbacks in main.ml)
>
> Sounds like there's consensus here.  Thomas, are you cooking up this patch?   
> We might be able to get away with simply hiding the `connect` function and 
> revving the signatures, and not doing a lot of minor releases.

Most libraries now explicitly declare "connect" (in their master
branches), which means they'll still work when we remove it from
mirage-types. These can be released at any time, as they also work
with the old signature.

There are three remaining patches, which need to be applied together:

- Modifying tcpip's stackv4 to take devices rather than IDs.
- Modifying mirage to pass devices to stackv4.
- Removing "connect" from DEVICE in mirage-types

They're all tracked here:

  https://github.com/mirage/mirage/pull/350

If necessary, we could modify the tcpip patch to add the new
constructor while keeping the old one, which would avoid needing to
synchronise across packages, but I think we decided to do it all at
once in the last call.

Once all this is released, we can remove the "with type id" bits from
the various libraries and then remove the "id" type from DEVICE too,
but there's no hurry there.

I've made a mirage-dev branch to test it here:

  https://github.com/mirage/mirage-dev/pull/54


-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

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