mbox series

[v7,00/21] error: prepare for auto propagated local_err

Message ID 20191205152019.8454-1-vsementsov@virtuozzo.com
Headers show
Series error: prepare for auto propagated local_err | expand

Message

Vladimir Sementsov-Ogievskiy Dec. 5, 2019, 3:19 p.m. UTC
Hi all!

This is the first part of the bit series, which contains mostly simple
cleanups.

v6 was sent in separate (I'm sorry for inconvenience)

v7: by Markus review (and with his prepared fixups, thanks a lot!):
  - don't rename Error** paramters
  - switch to Error *const * where appropriate
  last patch is new and replaces
   "nbd: well form nbd_iter_channel_error errp handler"

Vladimir Sementsov-Ogievskiy (21):
  hw/core/loader-fit: fix freeing errp in fit_load_fdt
  net/net: Clean up variable shadowing in net_client_init()
  error: rename errp to errp_in where it is IN-argument
  hmp: drop Error pointer indirection in hmp_handle_error
  vnc: drop Error pointer indirection in vnc_client_io_error
  qdev-monitor: well form error hint helpers
  ppc: well form kvmppc_hint_smt_possible error hint helper
  9pfs: well form error hint helpers
  hw/core/qdev: cleanup Error ** variables
  block/snapshot: rename Error ** parameter to more common errp
  hw/i386/amd_iommu: rename Error ** parameter to more common errp
  qga: rename Error ** parameter to more common errp
  monitor/qmp-cmds: rename Error ** parameter to more common errp
  hw/s390x: rename Error ** parameter to more common errp
  hw/sd: drop extra whitespace in sdhci_sysbus_realize() header
  hw/tpm: rename Error ** parameter to more common errp
  hw/usb: rename Error ** parameter to more common errp
  include/qom/object.h: rename Error ** parameter to more common errp
  backends/cryptodev: drop local_err from cryptodev_backend_complete()
  hw/vfio/ap: drop local_err from vfio_ap_realize
  nbd: assert that Error** is not NULL in nbd_iter_channel_error

Cc: "Gonglei (Arei)" <arei.gonglei@huawei.com>
Cc: Eric Blake <eblake@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>
Cc: Max Reitz <mreitz@redhat.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: Greg Kurz <groug@kaod.org>
Cc: Paul Burton <pburton@wavecomp.com>
Cc: Aleksandar Rikalo <aleksandar.rikalo@rt-rk.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: Cornelia Huck <cohuck@redhat.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Halil Pasic <pasic@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Tony Krowiak <akrowiak@linux.ibm.com>
Cc: Pierre Morel <pmorel@linux.ibm.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Cc: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: qemu-devel@nongnu.org
Cc: qemu-block@nongnu.org
Cc: qemu-ppc@nongnu.org
Cc: qemu-s390x@nongnu.org

 include/block/snapshot.h   |   2 +-
 include/monitor/hmp.h      |   2 +-
 include/qapi/error.h       |   6 +-
 include/qom/object.h       |   4 +-
 target/ppc/kvm_ppc.h       |   4 +-
 ui/vnc.h                   |   2 +-
 backends/cryptodev.c       |  11 +--
 block/nbd.c                |   1 +
 block/snapshot.c           |   4 +-
 dump/dump-hmp-cmds.c       |   4 +-
 hw/9pfs/9p-local.c         |   2 +-
 hw/9pfs/9p-proxy.c         |   2 +-
 hw/core/loader-fit.c       |   5 +-
 hw/core/machine-hmp-cmds.c |   6 +-
 hw/core/qdev.c             |  28 ++++---
 hw/i386/amd_iommu.c        |  14 ++--
 hw/ppc/spapr.c             |   2 +-
 hw/s390x/event-facility.c  |   2 +-
 hw/s390x/s390-stattrib.c   |   3 +-
 hw/sd/sdhci.c              |   2 +-
 hw/tpm/tpm_emulator.c      |   8 +-
 hw/usb/dev-network.c       |   2 +-
 hw/vfio/ap.c               |   9 +--
 monitor/hmp-cmds.c         | 155 ++++++++++++++++++-------------------
 monitor/qmp-cmds.c         |   2 +-
 net/net.c                  |  17 ++--
 qdev-monitor.c             |  16 ++--
 qga/commands-posix.c       |   2 +-
 qga/commands-win32.c       |   2 +-
 qga/commands.c             |  12 +--
 qom/qom-hmp-cmds.c         |   4 +-
 target/ppc/kvm.c           |   2 +-
 ui/vnc.c                   |  20 ++---
 util/error.c               |   6 +-
 34 files changed, 173 insertions(+), 190 deletions(-)

Comments

Cornelia Huck Dec. 5, 2019, 3:26 p.m. UTC | #1
On Thu,  5 Dec 2019 18:19:58 +0300
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> wrote:

> Hi all!
> 
> This is the first part of the bit series, which contains mostly simple
> cleanups.

What's the plan? Should subsystem maintainers pick up individual
patches, or will they be merged in one go?
Vladimir Sementsov-Ogievskiy Dec. 5, 2019, 4:03 p.m. UTC | #2
05.12.2019 18:26, Cornelia Huck wrote:
> On Thu,  5 Dec 2019 18:19:58 +0300
> Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> wrote:
> 
>> Hi all!
>>
>> This is the first part of the bit series, which contains mostly simple
>> cleanups.
> 
> What's the plan? Should subsystem maintainers pick up individual
> patches, or will they be merged in one go?
> 
The latter. Markus will take them all together.
Markus Armbruster Dec. 6, 2019, 8:44 a.m. UTC | #3
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> writes:

> 05.12.2019 18:26, Cornelia Huck wrote:
>> On Thu,  5 Dec 2019 18:19:58 +0300
>> Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> wrote:
>> 
>>> Hi all!
>>>
>>> This is the first part of the bit series, which contains mostly simple
>>> cleanups.
>> 
>> What's the plan? Should subsystem maintainers pick up individual
>> patches, or will they be merged in one go?
>> 
> The latter. Markus will take them all together.

Subsystem maintainers are welcome to take truly independent patches
through their trees if that's more convenient for them, say because it
avoids or reduces the likelihood of conflicts.

Whatever is left I will take through my tree.  Me taking everything is
slightly easier for me, and results in a more coherent git-log.  Neither
is serious enough to justify inconveniencing subsystem maintainers.