2010/11/27 Paul Brook <p...@codesourcery.com>: >> 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.
So you're with Blue's idea to put them in block/net layer. Yoshi > > Paul > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
