[Xen-tools] digression about writing solid code.

[Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

On Fri, 2005-07-29 at 13:35 -0400, Sean Dague wrote:
> On Fri, Jul 29, 2005 at 04:28:56PM +0100, harry wrote:
> > There's no good reason for any of this to fail so failure simply
> > shouldn't be an option.
> 
> First rule of software, things always fail.  There are plenty of reasons for
> things to fail.  A daemon died somewhere along the way, you ran out of
> resources to run in, you didn't have enough permissions, etc.

There's a reasonable explanation of what I meant by the above in the
book "Writing Solid Code" by Steve Maguire in the section "Don't Fail Me
Now" which is on page 100 in my edition. In short it says returning
errors when you don't have to is bad because the clients must handle the
errors which leads to bugs and code bloat.

> 
> If the software can't detect a failure in a useful way, and regroup then I
> certainly wouldn't run it on my network, and I definitely wouldn't trust it
> to run my virtual machines.

There's a difference between handling external failures which I consider
part of the normal path and internal failures.  The internal failures
that can affect configuration software are out-of-memory conditions and
failure of the physical machine running the software.  Out of memory
conditions can be avoided by using a strategy of pre-reserving the
resources required to perform an operation before starting it and the
configuration software can be made independent of simultaneous failure
of an arbitrary number of physical machines by running it inside a
fault-tolerant virtual machine.

So I'm sticking with what I said above: there really is no good reason
for the configuration software to ever fail (though it will often have
to be successful in correctly reporting external failures).

This is an example of the difference between a general purpose computing
mindset and an embedded systems mindset.  I think that the domain0 code
and xen-tools require more of an embedded systems approach precisely
because we want it to be continuously available and for people to trust
it to run their virtual machines.

> > Also, we are talking about the lowest level configuration interface here
> > which in practise will be an internal interface between the system
> > components and a higher level user GUI. So, I think there is a slightly
> > different trade-off desired here than ultimate ease-of-use.
> 
> Calling a python program the lowest level interface means we clearly have
> different definitions of lowest. ;)  libxenstore is the low level interface,
> xm & xend is a user interface.

It's the lowest level external interface. Also, I'd argue that
libxenstore is actually below the level of a configuration interface.

Harry


_______________________________________________
Xen-tools mailing list
Xen-tools@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-tools