On 09/11/2015 12:42 AM, Markus Armbruster wrote: > Quick initial high-level feedback, since I'm afraid real review will > take a while (series is long, and I'm still swamped). >
>> >> So the net result for these ARM machines, is error behaviour that is >> something like a compiler. If any one thing fails, then machine-init >> (compilation) fails. But an early fail does not stop machine-init >> (compilation), instead it proceeds to the end collecting subsequent >> errors as it goes. > > Simple compilers stop on first error. Not as bad as it may sound when > your machine gets from running "make" to compiler dying on the first > error real fast. > > More ambitious compilers continue to diagnose more errors. This isn't > trivial. The compiler has to satisfy post conditions even after an > error, typically by synthesizing suitable error values. It has to take > pains to avoid error cascades. Experienced users recognize when that > effort fails, and typically ignore the remaining errors wholesale then. > > In QEMU, error cascades might be less of a problem than with compilers. > To tell for sure, we'd have to try. > > However, satisfying post conditions is at least as much of a problem. > More so since they're generally unstated. Can you explain your strategy > for solving this one? And that's why I'm arguing that error chaining has to be an explicit opt-in, and not the default. Code that has been audited to be safe against cascading errors can use error chaining to reduce boilerplate, but the default behavior should continue to be treating the first error as fatal rather than getting the system into a worse state due to failed postconditions. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature