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

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 22 Jan 2015, at 10:27, Thomas Leonard <talex5@xxxxxxxxx> wrote:
> 
> One thing that bothers me about the Mirage types is the DEVICE.connect 
> function.
> 
> If I have e.g.
> 
> module MyMod (F : FS) = struct
>  let use f = ...
> end
> 
> then I'd expect that MyMod won't be able to corrupt the filesystem
> (assuming the FS itself isn't buggy).
> 
> But in fact MyMod can do:
> 
>  let use f =
>    let f2 = F.connect (F.id f)) in ...
> 
> and now we have two filesystems on the same underlying block device,
> which can't be good.
> 
> In OO terms, "connect" is the constructor (defined separately by each
> concrete implementation), while the other functions in DEVICE are
> methods (defined by the generic interface).
> 
> 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.
> 
> We should probably get rid of "id" as well. The signature says:
> 
>  type id
>  (** Type defining an identifier for this device that uniquely
>      identifies it among a device tree. *)
> 
>  val id : t -> id
>  (** Return the identifier that was used to construct this device *)
> 
> That might make sense for low-level Xen devices such as disks, but not
> for things built on them. For example, for an FS the "id" is the
> underlying block device. Perhaps it would be better to have a function
> "name : t -> string" for when you need a name for display? I don't see
> any particular reason why the user of a device should be able to
> recover the constructor arguments.
> 
> Thoughts?
> 

I'm in complete agreement -- the same design also applies to FLOW
(which doesn't define a connection function, only a close function).

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