Message ID | 20180713130916.4153-3-marcandre.lureau@redhat.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Fri, Jul 13, 2018 at 03:08:49PM +0200, Marc-André Lureau wrote: > There is no obvious reason to have a loop counter. This limits from > reading several megabytes large buffers in one go, since socket > read/write usually have a limit. The counter was there since this method's introduction in 7b0bfdf52d694c9a3a96505aa42ce3f8d63acd35, and no obvious indication of its purpose in that commit. I can imagine maybe it was a misguided attempt to prevent QEMU blocking forever if no data was pending, but it does not in fact achieve that. > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> > Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> > --- > chardev/char-fe.c | 6 +----- > 1 file changed, 1 insertion(+), 5 deletions(-) Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Regards, Daniel
diff --git a/chardev/char-fe.c b/chardev/char-fe.c index b1f228e8b5..f158f158f8 100644 --- a/chardev/char-fe.c +++ b/chardev/char-fe.c @@ -56,7 +56,7 @@ int qemu_chr_fe_write_all(CharBackend *be, const uint8_t *buf, int len) int qemu_chr_fe_read_all(CharBackend *be, uint8_t *buf, int len) { Chardev *s = be->chr; - int offset = 0, counter = 10; + int offset = 0; int res; if (!s || !CHARDEV_GET_CLASS(s)->chr_sync_read) { @@ -88,10 +88,6 @@ int qemu_chr_fe_read_all(CharBackend *be, uint8_t *buf, int len) } offset += res; - - if (!counter--) { - break; - } } if (qemu_chr_replay(s) && replay_mode == REPLAY_MODE_RECORD) {