Le 26/05/2022 à 15:49, Dan Carpenter a écrit :
On Thu, May 26, 2022 at 03:37:58PM +0200, Christophe JAILLET wrote:
Le 26/05/2022 à 14:00, Dan Carpenter a écrit :
On Thu, May 26, 2022 at 01:40:51PM +0200, Marion & Christophe JAILLET wrote:
Le 26/05/2022 à 13:07, Dan Carpenter a écrit :
On Thu, May 26, 2022 at 12:30:05PM +0200, Christophe JAILLET wrote:
Le 26/05/2022 à 11:51, Dan Carpenter a écrit :
All I know is that it seams to work for me, even if it has not detected any
issue yet :) (compiling takes SO MUCH time on my machine)
Yeah. :/ How big is your smatch_db.sqlite file?
I don't use any up-to-now.
Basically all my changes are targetted at making the smatch_db.sqlite
file smaller so they won't help you. Are you at least doing a parallel
build? The smatch_scripts/test_kernel.sh script does a make -j${NR_CPU}.
Yep.
I've also tweaked smatch_scripts/kchecker which doesn't have any -j, IIUC.
Normally, I only use kchecker on one file... The problem with doing
parallel builds is that you have to print the warnings to a file instead
of to stdout.
smatch.txt:
You can also build a directory like this:
~/progs/smatch/devel/smatch_scripts/kchecker drivers/whatever/
and up no now, it is mostly the wayIi use it, :)
I guess -j has no downside if you're building a single file.
The only problem is that if you're building a directory and sending
everything to stdout then the lines can get smooshed together. Is it
better to just let them smoosh or build the whole directory and then
find -name \*.c.smatch -exec cat \{\} \;?
Not sure to follow you.
I've not seen any problem yet with using:
../git_smatch/smatch_scripts/kchecker drivers/net/ > results.txt
CJ
regards,
dan carpenter
