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

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

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

MirageOS-devel mailing list



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