qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v1 00/21] RISC-V QEMU Port Submission v1


From: Alex Bennée
Subject: Re: [Qemu-devel] [PATCH v1 00/21] RISC-V QEMU Port Submission v1
Date: Fri, 05 Jan 2018 12:39:07 +0000
User-agent: mu4e 1.0-alpha3; emacs 26.0.90

Fam Zheng <address@hidden> writes:

> On Fri, 01/05 11:49, Alex Bennée wrote:
>>
>> Fam Zheng <address@hidden> writes:
>>
>> > On Wed, 01/03 15:54, Michael Clark wrote:
>> >> On Wed, Jan 3, 2018 at 3:41 PM, Fam Zheng <address@hidden> wrote:
>> >>
>> >> > On Wed, 01/03 15:00, Michael Clark wrote:
>> >> > > So it's essentially one error, the single line case pattern for
>> >> > > table-driven decode which flags for long lines and asks to separate 
>> >> > > break
>> >> > > onto its own line.
>> <snip>
>> >> > Thanks for taking a look! Practically, consistency with the rest of the
>> >> > code and
>> >> > human judgements (comments, explanation in replies etc.) often override 
>> >> > the
>> >> > checkpatch complaints. Checkpatch is not always right.
>> <snip>
>>
>> Fam,
>>
>> I wonder is there anyway we could signal to patchew that there are some
>> acknowledged and approved coding style variances in the patch? Would
>> something like:
>>
>>   CodingStyleExceptions: 12
>>
>> Be too polluting to the commit messages? Or perhaps something that can
>> skip individual tests on a given run:
>>
>>   CheckpatchFlags: --ignore-long-lines
>
> It sounds feasible. Putting these flags after a --- line will keep commit
> message clean.
>
> OTOH I think we should spend effort on patching checkpatch.pl to
> implement this.

I guess your right, given checkpatch is going to ingest the patch
anyway.

>
> Fam


--
Alex Bennée



reply via email to

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