> One question I have about Kemari is whether it adds new constraints to > the QEMU codebase? Fault tolerance seems like a cross-cutting concern > - everyone writing device emulation or core QEMU code may need to be > aware of new constraints. For example, "you are not allowed to > release I/O operations to the outside world directly, instead you need > to go through Kemari code which makes I/O transactional and > communicates with the passive host". You have converted e1000, > virtio-net, and virtio-blk. How do we make sure new devices that are > merged into qemu.git don't break Kemari? How do we go about > supporting the existing hw/* devices? IMO anything that requires devices to act differently is wrong. All external IO already goes though a common API (e.g. qemu_send_packet). You should be putting your transaction code there, not hacking individual devices. Paul -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
