2010/11/30 Stefan Hajnoczi <stefanha@xxxxxxxxx>: > On Tue, Nov 30, 2010 at 9:50 AM, Yoshiaki Tamura > <tamura.yoshiaki@xxxxxxxxxxxxx> wrote: >> 2010/11/29 Stefan Hajnoczi <stefanha@xxxxxxxxx>: >>> On Thu, Nov 25, 2010 at 6:06 AM, Yoshiaki Tamura >>> <tamura.yoshiaki@xxxxxxxxxxxxx> wrote: >>>> event-tap controls when to start FT transaction, and provides proxy >>>> functions to called from net/block devices. While FT transaction, it >>>> queues up net/block requests, and flush them when the transaction gets >>>> completed. >>>> >>>> Signed-off-by: Yoshiaki Tamura <tamura.yoshiaki@xxxxxxxxxxxxx> >>>> Signed-off-by: OHMURA Kei <ohmura.kei@xxxxxxxxxxxxx> >>>> --- >>>> Makefile.target | 1 + >>>> block.h | 9 + >>>> event-tap.c | 794 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> event-tap.h | 34 +++ >>>> net.h | 4 + >>>> net/queue.c | 1 + >>>> 6 files changed, 843 insertions(+), 0 deletions(-) >>>> create mode 100644 event-tap.c >>>> create mode 100644 event-tap.h >>> >>> event_tap_state is checked at the beginning of several functions. If >>> there is an unexpected state the function silently returns. Should >>> these checks really be assert() so there is an abort and backtrace if >>> the program ever reaches this state? > > Fancier error handling would work too. For example cleaning up, > turning off Kemari, and producing an error message with > error_report(). In that case we need to think through the state of > the environment carefully and make sure we don't cause secondary > failures (like memory leaks). Turning off Kemari should include canceling the transaction which notifies the secondary. So same as you commented for ft_trans_file error handling, I would implement better handling for event-tap again. >> BTW, I would like to ask a question regarding this. There is a >> callback which net/block calls after processing the requests, and >> is there a clean way to set this callback on the failovered >> host upon replay? > > I think this is a limitation in the current design. If requests are > re-issued by Kemari at the net/block level, how will the higher layers > know about these requests? How will they be prepared to accept > callbacks? That's why we're using pio/mmio replay at this moment. With a dirty hack in device emulators setting callbacks before replay, block/net replay seems to work, but I don't think that to be a correct solution. Yoshi > > Stefan > -- > 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 > -- 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
