[MirageOS-devel] RFC: disconnect / DEVICE lifetime

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

Hello,

On 30/09/2016 18:13, Hannes Mehnert wrote:
> So far, connect returns [ `Ok of 'a | `Error of 'b ] Lwt.t, and in the
> error case functoria emits a "fail (Failure <devicename>)".  This is
> clearly not very informative to potential users (an example being
> "Failure net11").

Thanks for everybody involved getting this change through.

I thought a bit more about the `DEVICE` module type.  I'm curious what
`disconnect : t -> unit io` is supposed to do, and who is supposed to
call it?  Its counterpart `connect` is called by auto-generated code
(from mirage) in `main.ml` during startup.  Should mirage as well
generate a `shutdown` function and invoke it after `start` finished?
This could ensure that disconnect is called in the reverse order of
connect, and once only.

My intuition about the contract of disconnect is: cleaning up state,
freeing resources (e.g. sending consumers messages about terminating
(TCP? TLS?) sessions, stopping Lwt listener threads, etc.)!?  Initially
[0] it was not intended to fully clean up resources!?

This leads to the lifetime of a DEVICE instance:  they can be demanded
by a unikernel (during configuration/build time), and must be present
(and in working operation) during runtime.  (In some future OCaml it'd
be nice to have linear types and be able to express that disconnect
consumes the given t.  But we're not there yet.)
There's at no time any need to dynamically allocate a DEVICE and use it
temporarily within the lifetime of a unikernel (please tell me if I'm
wrong and you've scenarios in mind where you want to spawn DEVICEs
dynamically [*]).

This also means that a user should never call disconnect on any DEVICE
where main.ml called connect (and there are no other DEVICEs).

This leads to the question what a disconnected DEVICE should do?  I'd be
in favour of undefined behaviour here, because an alternative (are there
better ones?) would be to check in every DEVICE operation that the
DEVICE state is not disconnected (as done currently in
mirage-block-unix, see [1] for what I have in mind), which imho
convolutes the control flow immensly.


TL;DR: emit disconnect chain in functoria/mirage, remove checks from
mirage-block-unix [tentative 1], remove more code ;)



Hannes

0:
https://github.com/mirage/mirage-types/commit/62b18ac0cee40895f45173f196fa6de58a56c076
1:
https://github.com/hannesm/mirage-block-unix/commit/f3de7fa7d3224d3c47a0e808e5e7cf650cfbf050
*: I thought about a DEVICE providing secrets only needed at startup
time, and then should be disconnected and destroyed.  But let's be fair,
in OCaml we cannot (atm) safely erase data from memory (due to GC it
might have moved, zeroing out is also not possible afaics).  Also, OCaml
already has this strong and safe type system, thus we shouldn't need
further defense mechanism in this scenario.

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