[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-tools] digression about writing solid code.
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |