[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH V5] block/nfs: add support for setting debug lev
Re: [Qemu-block] [PATCH V5] block/nfs: add support for setting debug level
Mon, 16 Nov 2015 11:27:30 -0500
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
On 11/15/2015 10:25 PM, Stefan Hajnoczi wrote:
> On Fri, Nov 13, 2015 at 10:52:49AM +0100, Peter Lieven wrote:
>> Am 13.11.2015 um 10:45 schrieb Stefan Hajnoczi:
>>> On Mon, Nov 09, 2015 at 08:09:33AM +0100, Peter Lieven wrote:
>>>> recent libnfs versions support logging debug messages. Add
>>>> support for it in qemu through an URL parameter.
>>>> qemu -cdrom nfs://127.0.0.1/iso/my.iso?debug=2
>>>> Signed-off-by: Peter Lieven <address@hidden>
>>>> v4->v5: add a comment in the code why we limit the debug level [Stefan]
>>>> v3->v4: revert to the initial version, but limit max debug level
>>>> v2->v3: use a per-drive option instead of a global one. [Stefan]
>>>> v1->v2: reworked patch to accept the debug level as a cmdline
>>>> parameter instead of an URI parameter [Stefan]
>>>> block/nfs.c | 12 ++++++++++++
>>>> 1 file changed, 12 insertions(+)
>>> Hi Peter,
>>> Please use my official maintainer email address <address@hidden>
>>> when CCing me. I didn't spot the mail to GMail until after the QEMU 2.5
>>> hard freeze deadline.
>> Okay. I think I used that email because you replayed to earlier versions
>> of this Patch from your Gmail address.
>>> Only bug fixes are being merged for QEMU 2.5 now. I'm sorry that this
>>> patch didn't make it. My block-next branch will be opening on Monday
>>> and I'll merge this patch there for QEMU 2.6.
>> Thats not critical in this case. I think same applies for the ATAPI stuff
>> we worked on? There you used also your GMail account. Or can this
>> be treated as a bugfix?
> The ATAPI patches go through John Snow. It's up to him whether they are
> considered a bug fix suitable for 2.5 or too risky.
I've tested them pretty thoroughly; I think they're safe (ATAPI-wise)
provided the buffered DMA helpers look sane (They look sane to me.) The
modifications to the giant atapi-return-code blob are well understood at
this point and are definitely fine.