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: Fam Zheng
Subject: Re: [Qemu-devel] [PATCH v1 00/21] RISC-V QEMU Port Submission v1
Date: Wed, 3 Jan 2018 11:05:56 +0800
User-agent: Mutt/1.9.1 (2017-09-22)

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.
> > >
> > > We have actually reduced the readability of other parts of the code to
> > > conform to this specific rule. In fact I spent a day and a half with
> > > checkpatch, but it didn't seem to make sense for the disassembler.
> > >
> > > The question is should one blindly comply with the rule for
> > > machine-generated tables. Editing the code manually introduces the
> > > potential for human error. I can, if needed, modify the disassembler
> > > generator to output code with the required verbosity.
> >
> > 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.
> 
> 
> Thanks.
> 
> Here is a run with [PATCH v1 04/21] removed to make the checkpatch output
> more readable. checkpatch is (perhaps incorrectly) flagging a request for
> space in a case value that is synthesised from a macro. Case values usually
> don't have space between the value and the colon. It's possibly because the
> case value is constructed from a macro and contains parenthesis. The other
> issue is consistency with existing source in scripts/qemu-binfmt-conf.sh as
> previously noted.

Agreed.

Fam



reply via email to

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