[MirageOS-devel] Remove DEVICE.connect?

[Thomas Leonard <talex5@xxxxxxxxx>]

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?


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