qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] block/curl: Implement the libcurl timer callbac


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] block/curl: Implement the libcurl timer callback interface
Date: Wed, 15 Jan 2014 21:56:34 +0000

On 15 January 2014 21:37, Richard W.M. Jones <address@hidden> wrote:
> On Wed, Jan 15, 2014 at 05:23:58PM +0000, Peter Maydell wrote:
>> libcurl versions 7.16.0 and later have a timer callback interface which
>> must be implemented in order for libcurl to make forward progress (it
>> will sometimes rely on being called back on the timeout if there are
>> no file descriptors registered). Implement the callback, and use a
>> QEMU AIO timer to ensure we prod libcurl again when it asks us to.
>
> Somewhat off topic, but does the curl driver work for you at all?
> Especially if you have a disk image on a remote server, but one with
> relatively low latency (eg. on a LAN but not localhost).

I haven't attempted to use it in anger. I just found that it was hanging
completely when I tried a test case for the modules code, investigated
a bit, found that libcurl requires this timer callback, implemented it
and determined that my test case at least started to boot from the remote
image.

> We have had endless problems with it, including upstream discussions
> with curl people, summarised in this bug:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=971790

Looking through the thread from upstream, I see they basically
said "you need to implement the timer callback" :-)

> Just now I tried the latest qemu from git with and without your patch
> and still cannot make it work, although the bugginess is now different
> from RHBZ#971790.  I opened a new bug about what I'm seeing today
> (https://bugs.launchpad.net/qemu/+bug/1269606).

This should be relatively easy to debug, because that "Error opening file"
case happens very early on, in curl_open(), before we even try to use the
curl-multi interface or do anything event driven or AIO based, only for
the case where something went wrong during the initial "HEAD"
operation to get the size and confirm the server supports HTTP ranges.
You should be able to just throw a pile of debugging at curl_open() to
see what's actually failing.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]