qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] Give detailed info when pcie downstream port in


From: Cao jin
Subject: Re: [Qemu-devel] [PATCH] Give detailed info when pcie downstream port init failed
Date: Sat, 28 Nov 2015 15:23:49 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0


On 11/27/2015 10:22 PM, Markus Armbruster wrote:
Cao jin <address@hidden> writes:

Hi, Markus

On 11/24/2015 06:08 PM, Markus Armbruster wrote:
[...]

and this will cover to output to the monitor, right?

The device still implements the old PCIDeviceClass.init() instead of the
new .realize().  All devices need to be converted to .realize().  You
can help by converting this one.

.init() reports errors with error_report() and returns 0 on success, -1
on failure.

.realize() passes errors to its callers via its errp argument.


After reading you commit 28b07e7, I am aware of this;) Thanks very much for your detailed explanation:) I was always curious about why there are 2 function(.init() & .realize()) for initializing device, now I guess I get it: it has just .init() at first, because of error report issue, the .realize() is added to replace it, in order to pass the error above. Do I understand it right ?

If I understand it right, I see there are still devices initialization using .init() of DeviceClass & PCIDeviceClass, maybe I can help to convert some of these.

Commit 28b07e7 can serve as example of how to convert a device to
realize().  There are many more.  The ones I did usually have "Convert
to realize()" in the commit message's first line.


Regarding six error paths: I counted six places that return -1 directly
or goto err or similar.  Your patch adds a suitable error message to one
of them.  The other five need one, too.  You'll have to examine the
called functions to find out whether they report anything.  If they do,
they need to be first converted to pass an Error to their callers
instead.


It seems I have a misunderstanding about the "6 error paths":-[ I thought "error path" is a "error *reporting path*", like: fprintf the msg to stderr is a path, while output it via QMP is also a path. Because I did`t touch the code about -chardev/-mon/-monitor/-qmp before, so I spent 2 days reading the code:)

Now I am cleared, Thanks you very much for the clarifying, Markus, I think this mistake won`t happen to me later;) And actually, I was already thinking add suitable error msg to each error path:)

.


--
Yours Sincerely,

Cao Jin





reply via email to

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