Re: [PATCH v1 1/3] media: staging: tegra-vde: Support reference picture marking

Re: [PATCH v1 1/3] media: staging: tegra-vde: Support reference picture marking

[Dan Carpenter]

On Thu, Nov 18, 2021 at 04:56:38PM +0300, Dmitry Osipenko wrote:
> 18.11.2021 09:14, Dan Carpenter пишет:
> > It's not hard to run Smatch yourself...
> > 
> > Depending on if you're on a apt distro or yum distro then fetch the
> > dependencies with one of the follow commands:
> > apt-get install gcc make sqlite3 libsqlite3-dev libdbd-sqlite3-perl libssl-dev libtry-tiny-perl
> > yum install gcc make sqlite3 sqlite-devel sqlite perl-DBD-SQLite openssl-devel perl-Try-Tiny
> > 
> > git clone https://github.com/error27/smatch 
> > cd smatch
> > make
> > cd ~/kernel_source/
> > ~/smatch/smatch_scripts/kchecker drivers/subsystem/
> 
> Thanks, I was running Smatch couple times in the past. Finding how to
> run Smatch isn't the problem, the thing is that Smatch either isn't
> packaged by distros or packaged version is outdated, hence there is a
> need to maintain it by yourself.
> 
> Also, is it guaranteed that Smatch will always work properly with
> linux-next?

I work against linux-next every day so generally, yes.  But that reminds
me that linux-next broke while I was on vacation and I haven't yet
pushed the fixes.

> 
> I imagine more developers could start to engage in using Smatch if
> kernel supported 'make smatch' command which would automate the process
> of fetching, building and running Smatch.
> 
> Couldn't the "kernel" version of Smatch reside in the kernel's tools/?
> Or maybe just the parts of Smatch that are necessary for kernel
> checking, like kernel's DB/scripts and etc. Doesn't it make sense?

I'm not sure that makes sense really...  I'll expand on that in a bit
but the shorter answer is also that I don't have the bandwidth to make
it work.  I just suck at releases and testing.  So this would bitrot and
be horrible.

Smatch does need a better way to manage data for other projects.  Right
now linux-next is the first class citizen.  It's the only thing where
I'm positive that it gets tested regularly.  All the data in
smatch_data/ is from linux-next.

And also there should be a better way to check specific version of the
kernel because people quite often use the same directory and just check
out v4.12 to test that and switch back.  I do that and I've got scripts
on my system ./switch_to_tree4v1.sh which set up the symlinks for me.

But for linux-next it's fine.  Also by the time kernels have been
released the remaining Smatch warnings are almost all false positives.

To me the data in smatch_data/ is not so important as the cross function
database.  And the cross function database can't be distributed.  It's
too huge and it's specific to a given .config.

regards,
dan carpenter

Re: [PATCH v1 1/3] media: staging: tegra-vde: Support reference picture marking

[Dmitry Osipenko]

19.11.2021 15:30, Dan Carpenter пишет:
> On Thu, Nov 18, 2021 at 04:56:38PM +0300, Dmitry Osipenko wrote:
>> 18.11.2021 09:14, Dan Carpenter пишет:
>>> It's not hard to run Smatch yourself...
>>>
>>> Depending on if you're on a apt distro or yum distro then fetch the
>>> dependencies with one of the follow commands:
>>> apt-get install gcc make sqlite3 libsqlite3-dev libdbd-sqlite3-perl libssl-dev libtry-tiny-perl
>>> yum install gcc make sqlite3 sqlite-devel sqlite perl-DBD-SQLite openssl-devel perl-Try-Tiny
>>>
>>> git clone https://github.com/error27/smatch 
>>> cd smatch
>>> make
>>> cd ~/kernel_source/
>>> ~/smatch/smatch_scripts/kchecker drivers/subsystem/
>>
>> Thanks, I was running Smatch couple times in the past. Finding how to
>> run Smatch isn't the problem, the thing is that Smatch either isn't
>> packaged by distros or packaged version is outdated, hence there is a
>> need to maintain it by yourself.
>>
>> Also, is it guaranteed that Smatch will always work properly with
>> linux-next?
> 
> I work against linux-next every day so generally, yes.  But that reminds
> me that linux-next broke while I was on vacation and I haven't yet
> pushed the fixes.
> 
>>
>> I imagine more developers could start to engage in using Smatch if
>> kernel supported 'make smatch' command which would automate the process
>> of fetching, building and running Smatch.
>>
>> Couldn't the "kernel" version of Smatch reside in the kernel's tools/?
>> Or maybe just the parts of Smatch that are necessary for kernel
>> checking, like kernel's DB/scripts and etc. Doesn't it make sense?
> 
> I'm not sure that makes sense really...  I'll expand on that in a bit
> but the shorter answer is also that I don't have the bandwidth to make
> it work.  I just suck at releases and testing.  So this would bitrot and
> be horrible.
> 
> Smatch does need a better way to manage data for other projects.  Right
> now linux-next is the first class citizen.  It's the only thing where
> I'm positive that it gets tested regularly.  All the data in
> smatch_data/ is from linux-next.
> 
> And also there should be a better way to check specific version of the
> kernel because people quite often use the same directory and just check
> out v4.12 to test that and switch back.  I do that and I've got scripts
> on my system ./switch_to_tree4v1.sh which set up the symlinks for me.
> 
> But for linux-next it's fine.  Also by the time kernels have been
> released the remaining Smatch warnings are almost all false positives.
> 
> To me the data in smatch_data/ is not so important as the cross function
> database.  And the cross function database can't be distributed.  It's
> too huge and it's specific to a given .config.

Thank you for the clarification.