[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] checkpatch.pl: disable arch-specific test for l
From: |
Riku Voipio |
Subject: |
Re: [Qemu-devel] [PATCH] checkpatch.pl: disable arch-specific test for linux-user |
Date: |
Tue, 27 Sep 2016 02:36:34 +0300 |
On 27 September 2016 at 00:08, Peter Maydell <address@hidden> wrote:
> On 26 September 2016 at 12:58, <address@hidden> wrote:
>> From: Riku Voipio <address@hidden>
>>
>> Linux-user and bsd-user code needs lots of arch-specific ifdefs,
>> so disable the warning.
>>
>> Signed-off-by: Riku Voipio <address@hidden>
>> ---
>> scripts/checkpatch.pl | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
>> index dde3f5f..98a007f 100755
>> --- a/scripts/checkpatch.pl
>> +++ b/scripts/checkpatch.pl
>> @@ -2405,8 +2405,9 @@ sub process {
>> }
>> # check of hardware specific defines
>> # we have e.g. CONFIG_LINUX and CONFIG_WIN32 for common cases
>> -# where they might be necessary.
>> - if ($line =~ address@hidden@) {
>> +# where they might be necessary. Skip test on linux-user and bsd-user
>> +# where arch defines are needed
>> + if (!($realfile =~ /^(linux|bsd)-user/) && $line =~
>> address@hidden@) {
>> ERROR("architecture specific defines should be
>> avoided\n" . $herecurr);
>> }
>
> Do you have some examples of the false positives you want
> to suppress here? For new code I would hope that we can
> handle host-arch-specifics by having new files (or just
> new #defines etc) in linux-user/host/$ARCH/ rather than
> inline #ifdeffery in the main files.
One example from your patch:
https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg05650.html
And another from Laurent:
https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg06486.html
Every new syscall will comes with "#ifdef TARGET_NR_foo and
defined(__NR_foo)", while host/target combos catch up. Now, most
TARGET_NR_foo's are needed only for unicore32, but the __NR_foo
defines will be needed for a very long time.
Riku