[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.

I was going to wait for the my other batch of API changes
("error_message") to get accepted first, but we can do it in parallel.
Here's a tracking PR:


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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.