On 22 Jan 2015, at 10:27, Thomas Leonard <[email protected]> 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 [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
