Re: [PATCH 2/3] add memory asm constraint for PPC

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

 




On 04/07/2020 20:32, Luc Van Oostenryck wrote:
> On Sat, Jul 04, 2020 at 06:44:53PM +0100, Ramsay Jones wrote:

>> On 04/07/2020 14:57, Luc Van Oostenryck wrote:
>>> The 'Z' asm constraint is used for doing IO accessors on PPC but
>>> isn't part of the 'common constraints'. It's responsible for
>>> more than half of all warnings (with defconfig + allyesconfig).
>>
>> Not a problem, but this made me think 'half of which warnings'. :-D
>> I assume, but it's just a guess, this means 'half of all asm-constraints
>> warnings on the kernel PPC build'.
>>
>> How many warnings is that? What percentage is that of _all_ sparse
>> warnings on a typical kernel build?
> 
> It's literally more than half of all warnings issued by sparse when doing
> a build of the kernel with 'defconfig' and another one with 'allyesconfig'
> (all my tests on kernel builds are done like so) on a ppc64 machine:
> 	$ grep ': \(error\|warning\):' log-master-master | wc -l
> 	138581
> 	$ grep ': \(error\|warning\):' log-arch-asm-mem | wc -l
> 	50006
> So, this series eliminates about 64% of all warnings, a nice
> improvement of the S/N ratio.

Oh, nice!

It's a _long_ time since I last built the kernel (about when reading
Greg's 'Linux Kernel in a Nutshell' book, so about 2006), and I don't
even recall if I ran sparse over it. (Hmm, did you have to specify
a C parameter to make or something?).

Anyway, that is still a very large number of error/warnings - has it
always been that bad?

>> [BTW, I also noticed the (long running) 'luc/options' branch, which
>> looks like it could prove to be a nice cleanup - I've only read the
>> commit messages, not the actual commits.]
> 
> Yes, I think it's a nice cleanup because this code is quite messy but,
> OTOH, moving around all this code break all its history (via 'git blame'
> or 'git log -L') is is guaranteed to create really nasty conflicts with
> anything touching the code for the options. This is really a downside.

Yep, I know what you mean. However, I don't think you should shy
away from clean-ups for too long - it will be counter-productive
in the end.

ATB,
Ramsay Jones




[Index of Archives]     [Newbies FAQ]     [LKML]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Trinity Fuzzer Tool]

  Powered by Linux