qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v7 03/10] pci: Convert msix_init() to Error and


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v7 03/10] pci: Convert msix_init() to Error and fix callers to check it
Date: Wed, 11 Jan 2017 10:55:24 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Paolo Bonzini <address@hidden> writes:

> On 10/01/2017 18:54, Michael S. Tsirkin wrote:
>> On Mon, Nov 14, 2016 at 03:25:33PM +0800, Cao jin wrote:
>>> msix_init() reports errors with error_report(), which is wrong when
>>> it's used in realize().  The same issue was fixed for msi_init() in
>>> commit 1108b2f.
>>>
>>> For some devices(like e1000e, vmxnet3) who won't fail because of
>>> msix_init's failure, suppress the error report by passing NULL error object.
>>>
>>> Bonus: add comment for msix_init.
>>>
>>> CC: Jiri Pirko <address@hidden>
>>> CC: Gerd Hoffmann <address@hidden>
>>> CC: Dmitry Fleytman <address@hidden>
>>> CC: Jason Wang <address@hidden>
>>> CC: Michael S. Tsirkin <address@hidden>
>>> CC: Hannes Reinecke <address@hidden>
>>> CC: Paolo Bonzini <address@hidden>
>>> CC: Alex Williamson <address@hidden>
>>> CC: Markus Armbruster <address@hidden>
>>> CC: Marcel Apfelbaum <address@hidden>
>>>
>>> Reviewed-by: Markus Armbruster <address@hidden>
>>> Reviewed-by: Hannes Reinecke <address@hidden>
>>> Signed-off-by: Cao jin <address@hidden>
>> 
>> I'd rather add a new API. Once that is merged you can make device
>> changes avoiding a flag day. Merge this through individual trees. At the
>> end of the day we can drop the old API when it's no longer needed.
>
> I think that's the worst.  We don't need another partial transition and

Seconded.

> this series is all but big.  The main issue is that it was handled badly
> in the past, so people tend not to trust it.
>
> If anything, if there are independent patches in the series that can be
> merged through USB or SCSI trees, before this one, we can do that.

I guess some of the later patches are follow-up cleanups that could be
merged separately.  Might require reordering, then re-review.  But would
this really be worth the trouble?  Merging through another tree is no
pixie dust for quality.  If we can get the review and testing we need
only by merging every shard through the exact right tree, we're doing it
wrong.

Yes, we absolutely want a maintainer to review patches, and yes, that's
not trivial for work spanning subsystems.  But we got the R-bys alright.

Elsewhere in this thread, you ask for specific testing in addition to a
maintainer's R-by.  I think that's fair.



reply via email to

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