[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <96bd9677-c257-480b-be3c-7c4b9b79b238@redhat.com>
Date: Thu, 24 Apr 2025 16:02:00 +0200
From: Felix Maurer <fmaurer@...hat.com>
To: Vincent Mailhol <mailhol.vincent@...adoo.fr>
Cc: socketcan@...tkopp.net, mkl@...gutronix.de, shuah@...nel.org,
davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, horms@...nel.org, linux-can@...r.kernel.org,
netdev@...r.kernel.org, linux-kselftest@...r.kernel.org,
dcaratti@...hat.com, fstornio@...hat.com
Subject: Re: [PATCH 1/4] selftests: can: Import tst-filter from can-tests
On 24.04.25 09:42, Vincent Mailhol wrote:
> On Tue. 22 Apr. 2025 at 21:08, Felix Maurer <fmaurer@...hat.com> wrote:
[...]
>> +ALL_TESTS="
>> + test_raw_filter
>> +"
>> +
>> +net_dir=$(dirname $0)/..
>> +source $net_dir/lib.sh
>> +
>> +VCANIF="vcan0"
>
> Here, you are making the VCANIF variable configuration, but then, in
> your test_raw_filter.c I see:
>
> #define VCANIF "vcan0"
>
> This means that in order to modify the interface, one would have to
> both modify the .sh script and the .c source. Wouldn't it be possible
> to centralize this? For example by reading the environment variable in
> the C file?
>
> Or maybe there is a smarter way to pass values in the kernel selftests
> framework which I am not aware of?
Good point, I'll try to come up with something to avoid the duplication
(either from the selftest framework or just for the CAN tests). I'd
prefer an argument to the program though, as I find this the more usual
way to pass info if one ever wants to run the test directly.
>> +setup()
>> +{
>> + ip link add name $VCANIF type vcan || exit $ksft_skip
>> + ip link set dev $VCANIF up
>> + pwd
>> +}
>> +
>> +cleanup()
>> +{
>> + ip link delete $VCANIF
>> +}
>
> I guess that this setup() and this cleanup() is something that you
> will also need in the other can tests. Would it make sense to declare
> these in a common.sh file and just do a
>
> source common.sh
>
> here?
I usually try to avoid making changes in anticipation of the future. I'm
not sure if all the tests need a similar environment and would prefer to
split this when we encounter that they do. Are you okay with that?
Thanks,
Felix
Powered by blists - more mailing lists