Hi Dan,

> On 23 Jun 2025, at 16:31, Dan Carpenter <[email protected]> wrote:
> 
> On Mon, Jun 23, 2025 at 04:04:23PM +0000, Miguel Luis wrote:
>>>>>> 
>>>>>> make clean && make CHECK="../smatch/smatch -p=kernel --info 
>>>>>> --file-output" C=1 -j $(nproc) Image || make -j $(nproc) Image
>>>>>> export WLOG="warns.txt"
>>>>>> find -name *.c.smatch -exec cat {} \; -exec rm {} \; > $WLOG
>>>>>> find -name *.c.smatch.sql -exec cat {} \; -exec rm {} \; > $WLOG.sql
>>>>>> find -name *.c.smatch.caller_info -exec cat {} \; -exec rm {} \; > 
>>>>>> $WLOG.caller_info
>>>>>> 
>>>>> 
>>>>> 
>>>>> s/>/>>
>>>>> 
>>>>> To append to file instead.
>>>>> 
>>>> 
>>>> Those files are only used once...  Keeping the old data seems like it
>>>> might cause a problem.
>> 
>> Now I get it, whether one removes $WLOG* or keep them and use ‘>’ will get 
>> the same result.
>> 
> 
> Huh...  I'm surprised by that, actually.  To be honest, I'm not sure I
> understand what you're doing.

I’m starting to get the feeling of using smatch to try find an answer to the 
original issue this thread carries (1st message).

>  I assume you're either building part of
> the kernel tree only to save time

Yes, that’s about it. I don’t need to wait "for 6 hours” to get the results 
solely for the interested part of the code I’m triaging hence I’ve decoupled 
building modules I don’t care and focused solely on the monolithic part.

> and then adding more files to it
> later.

No.

>  Or maybe you're updating Smatch

Yes, I do intend to do that if I need to while I don’t get the final answer to 
the original problem of this thread. Whether it keeps flowing will depend on 
how attached I'll feel about the tool: so far, so interesting.

> an rebuilding the database based
> on the new code.
> 
> If you're building new kernel modules, then this should work.  But if
> you're rebuilding stuff then you'd want to delete the old information
> from the DB before loading the new stuff.

I agree.

> 
>>> 
>>> I agree and based on that this is the script I’m using:
>> 
>> .. however, I still get the same number of $((`cat smatch_warns.txt | wc -l` 
>> - `cat smatch_warns.txt | uniq | wc -l`)) duplicates.
>> 
> 
> I'm totally confused what you're saying here, sorry.  :P

What I’m saying is there’s a relatively considerable number of duplicated 
entries in ’smatch_warns.txt’ and this is how my argument got that confirmed:

$((`cat smatch_warns.txt | wc -l` - `cat smatch_warns.txt | uniq | wc -l`))

>  The SQL
> is mostly pulled into smatch_warns.txt.sql and smatch_warns.txt.call_info.

Got that but I’m still a bit lost here, so in my script ‘create_db.sh’ is using 
smatch_warns.txt.sql solely, should ‘smatch_warns.txt.call_info’ be passed to 
‘create_db.sh’ too or how does that information gets into the db?

> 
> regards,
> dan carpenter
> 

Thanks
Miguel

Reply via email to