All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Cao jin <caoj.fnst@cn.fujitsu.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>,
	qemu-devel@nongnu.org, mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH RFC v2 1/2] Add param Error** to msi_init() & modify the callers
Date: Wed, 23 Mar 2016 09:12:39 +0100	[thread overview]
Message-ID: <87zitpd348.fsf@blackfin.pond.sub.org> (raw)
In-Reply-To: <56F215C0.60203@cn.fujitsu.com> (Cao jin's message of "Wed, 23 Mar 2016 12:04:16 +0800")

Cao jin <caoj.fnst@cn.fujitsu.com> writes:

> On 03/02/2016 05:13 PM, Markus Armbruster wrote:
>> This got lost over the Christmas break, sorry.
>>
>> Cc'ing Marcel for additional PCI expertise.
>>
>> Cao jin <caoj.fnst@cn.fujitsu.com> writes:
>>
>>> msi_init() is a supporting function in PCI device initialization,
>>> in order to convert .init() to .realize(), it should be modified first.
>>
>> "Supporting function" doesn't imply "should use Error to report
>> errors".  HACKING explains:
>>
>>      Use the simplest suitable method to communicate success / failure to
>>      callers.  Stick to common methods: non-negative on success / -1 on
>>      error, non-negative / -errno, non-null / null, or Error objects.
>>
>>      Example: when a function returns a non-null pointer on success, and it
>>      can fail only in one way (as far as the caller is concerned), returning
>>      null on failure is just fine, and certainly simpler and a lot easier on
>>      the eyes than propagating an Error object through an Error ** parameter.
>>
>>      Example: when a function's callers need to report details on failure
>>      only the function really knows, use Error **, and set suitable errors.
>>
>>      Do not report an error to the user when you're also returning an error
>>      for somebody else to handle.  Leave the reporting to the place that
>>      consumes the error returned.
>>
>
> Really appreciate your review, I just finished reading all the
> comments and discussion.
>
> Seems pci_add_capability2()(commit cd9aa33e introduced) doesn`t follow
> the new error reporting rule(report error while also return error).

Misunderstanding?

"Report an error to the user" means error_report() and such.
error_setg() doesn't report to the user, it returns an error object to
the caller.

> So I am thinking, could we revert commit cd9aa33e, let
> pci_add_capability() return error code and assert when out of pci
> space, and let caller(only assigned device, others could ignore the
> error) handle the error code(new a error object, propagate it)
>
> Hope to hear PCI Maintainer`s advice(So I don`t cc other in this round)

  reply	other threads:[~2016-03-23  8:12 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-15 10:43 [Qemu-devel] [PATCH RFC v2 0/2] MSI/MSIX: fix to catch and report errors Cao jin
2015-12-15 10:43 ` [Qemu-devel] [PATCH RFC v2 1/2] Add param Error** to msi_init() & modify the callers Cao jin
2016-03-02  9:13   ` Markus Armbruster
2016-03-03  3:56     ` Cao jin
2016-03-03 10:12     ` Marcel Apfelbaum
2016-03-03 10:45       ` Michael S. Tsirkin
2016-03-03 11:19         ` Marcel Apfelbaum
2016-03-03 11:33           ` Michael S. Tsirkin
2016-03-03 15:03             ` Markus Armbruster
2016-03-03 18:33               ` Michael S. Tsirkin
2016-03-04  8:42                 ` Markus Armbruster
2016-03-04  9:24                   ` Michael S. Tsirkin
2016-03-04 12:57                     ` Markus Armbruster
2016-03-04 13:10                       ` Michael S. Tsirkin
2016-03-03 14:24       ` Markus Armbruster
2016-03-23  4:04     ` Cao jin
2016-03-23  8:12       ` Markus Armbruster [this message]
2016-03-23  9:23         ` Cao jin
2015-12-15 10:43 ` [Qemu-devel] [PATCH v2 RFC 2/2] Add param Error** to msix_init() " Cao jin
2015-12-17  8:02 ` [Qemu-devel] [PATCH RFC v2 0/2] MSI/MSIX: fix to catch and report errors Cao jin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zitpd348.fsf@blackfin.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=caoj.fnst@cn.fujitsu.com \
    --cc=marcel@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.