Re: [Xen-devel] [PATCH V13 3/5] libxl: add pvusb API

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

George Dunlap writes ("Re: [Xen-devel] [PATCH V13 3/5] libxl: add pvusb API"):
> There's a difference between "making it intelligent" and "not making it
> broken". :-)  Given that users can potentially cause a number of these
> things to fail just by pressing Ctrl-C, we need to at least make sure
> that we don't get into a completely wedged state that the user can't do
> anything to fix.  That requires some careful thought.

Right.  There is a useful design principle which can help simplify and
clarify: "crash-only software".[1][2]

The idea is that when an error occurs, it is usually best to simply
stop and leave the system in whatever intermediate state.  The next
run of the software is responsible for discovering, interpreting and
if necessary rectifying the situation.

In general these recovery paths are necessary anyway.  So the
on-error-cleanup doesn't help.


In the context of that series, I think that means:

We observe that there is an ordering of possible states
      attached to dom0 driver
      unattached
      attached to usbback
      assigned to a guest

When reconfiguring a device, it will move through these states in
order (forwards or backwards, normally).

NB that I don't discuss here what information may be recorded in
xenstore and the VM configuration at each stage: so in fact there are
various micro-states in between the major states shown above (eg,
"attached to usbback and in process of attaching to geust").


To make a coherent design, we need to:

Arrange that each of these states can be seen by the user somehow.
(Eg in output from list-assignable.)

Arrange that each intermediate state can be recovered to at least one
endpoint state by use of some appropriate command(s).

Arrange that the recording of metadata in xenstore and the domain json
config occurs in the right order to support the above (ie, that the
micro-states are right).  After an approach has been chosen, to show
that the design is correct, it is probably easiest to explicitly
enumerate all the micro-states.


Ideally I would like to see this aspect of the design covered in a doc
comment (or maybe commit messages), in some form or other.


I hope this is of some help.

Thanks,
Ian.


[1] https://www.usenix.org/events/hotos03/tech/full_papers/candea/candea.pdf
[2] https://en.wikipedia.org/wiki/Crash-only_software

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel