[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 01/16] checkpatch: Add xendevicemodel_handle to
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [PATCH 01/16] checkpatch: Add xendevicemodel_handle to the list of types |
Date: |
Thu, 26 Apr 2018 09:21:40 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 |
On 04/26/2018 06:06 AM, Ian Jackson wrote:
> (expanding the CC to include everyone that get_maintainer suggests)
>
> Ian Jackson writes ("[PATCH 01/16] checkpatch: Add xendevicemodel_handle to
> the list of types"):
>> This avoids checkpatch misparsing (as statements) long function
>> definitions or declarations, which sometimes start with constructs
>> like this:
>>
>> static inline int xendevicemodel_relocate_memory(
>> xendevicemodel_handle *dmod, domid_t domid, ...
>>
>> The type xendevicemodel_handle does not conform to Qemu CODING_STYLE,
>> which would suggest CamelCase. However, it is a type defined by the
>> Xen Project in xen.git. It would be possible to introduce a typedef
>> to allow the qemu code to refer to it by a differently-spelled name,
>> but that would obfuscate more than it would clarify.
>
> This patch has been posted in substantially similar form quite a few
> times now. Paolo Bonzini understandably suggested that renaming the
> variable would be better but that's not within qemu's bailiwick as I
> say above.
>
> I think everything else in this series has a review and/or an ack.
> So I would like to send a pull request.
>
> Does someone want to review this patch ? Should I drop it and just
> let checkpatch complain ? Shold I include it in my pull request
> anyway ?
If no one has commented on what seems pretty trivial (especially since
checkpatch.pl has no official maintainer, but is more of a
"whoever-touched-it-last" file at the moment), then including the patch
in your pull request is perfectly acceptable. As a maintainer, it is
also perfectly acceptable for you to ignore false positives from
checkpatch (although documenting it in the commit message and/or cover
letter never hurts, when you are intentionally ignoring a false positive).
But, as there has also been a recent patch to teach checkpatch about
glib types [1], your patch makes sense (any merge conflict between your
patch and that one will be obvious to resolve). So on that grounds,
Reviewed-by: Eric Blake <address@hidden>
[1] https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg04179.html
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
- [Qemu-devel] [PATCH v8 00/16] xen: xen-domid-restrict improvements, Ian Jackson, 2018/04/24
- [Qemu-devel] [PATCH 02/16] AccelClass: Introduce accel_setup_post, Ian Jackson, 2018/04/24
- [Qemu-devel] [PATCH 04/16] xen: restrict: use xentoolcore_restrict_all, Ian Jackson, 2018/04/24
- [Qemu-devel] [PATCH 03/16] xen: link against xentoolcore, Ian Jackson, 2018/04/24
- [Qemu-devel] [PATCH 05/16] xen: defer call to xen_restrict until just before os_setup_post, Ian Jackson, 2018/04/24
- [Qemu-devel] [PATCH 09/16] os-posix: cleanup: Replace fprintfs with error_report in change_process_uid, Ian Jackson, 2018/04/24
- [Qemu-devel] [PATCH 07/16] xen: move xc_interface compatibility fallback further up the file, Ian Jackson, 2018/04/24
- [Qemu-devel] [PATCH 10/16] os-posix: Provide new -runas <uid>:<gid> facility, Ian Jackson, 2018/04/24