On Wed, Apr 8, 2015 at 1:38 AM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > On Tue, Apr 7, 2015 at 9:08 PM, Peter Lieven <p...@kamp.de> wrote: > > Please CC qemu-devel@nongnu.org in the future. All patches must be on > the qemu-devel mailing list so they can be merged (for transparency). > I have added qemu-devel to CC. > >> + /* newer versions of libiscsi may return zero events. In this >> + * case start a timer to ensure we are able to return to service >> + * once this situation changes. */ >> + if (!ev) { >> + timer_mod(iscsilun->event_timer, >> + qemu_clock_get_ms(QEMU_CLOCK_REALTIME) + EVENT_INTERVAL); >> } > > This suggests that libiscsi is waiting on its own internal timer. It > would be cleaner for libiscsi to provide a timeout value so the > application doesn't need to poll the library. Is there still scope to > modify libiscsi to do this?
I think that returning a timeout value would be a bigger change in the API that Peter wanted to avoid. We discussed that as an option by my take from it was that this would require that qemu and libiscsi again would have to be updated in lockstep, In this particular case with creating a delay between failed reconnect attempts, i.e. the target is restarting and returning a RST to the SYN request until it has fully restarted, the correct amount of time to wait until re-trying is at best a guess anyway. I don't have any particular feelings on whether the decision on how long to wait is done inside libiscsi and communicated to qemu, or if it is done in qemu itself. The nice part with the current patch of Peter is that qemu and libiscsi can be upgraded/downgraded independently.