On 9/3/26 23:59, Andrew Lunn wrote:
>> But then there's the kselftests that require a peer, and here it's another
>> story.
>> Some tests, when using the SSH remote type, will scp a small binary on the
>> peer
>> and use that binary for testing (sending specially crafted frames, etc.)
>>
>> Just in the drivers/net/hw tests, we have :
>>
>> drivers/net/hw/csum.py
>> drivers/net/hw/devmem_lib.py
>> drivers/net/hw/gro_hw.py
>> drivers/net/hw/iou-zcrx.py
>> drivers/net/hw/nk_qlease.py
>
> But none of these are binary, so long as you run the .py file, not a
> pyc file.
>
> iou-zcrx.c ncdevmem.c nk_forward.bpf.c nk_primary_rx_redirect.bpf.c
> toeplitz.c would be a problem.
What I meant is that all the .py files above are selftests that are copying
actual biniares (generated from the c files you mention)
e.g.
drivers/net/hw/csum.py sends the binary generated from net/lib/csum.c to the
peer
>
>> We could expand the remote_ssh logic to probe the peer, and raise a skip if
>> it's
>> a different arch than the dut. Or better, have the DUT check if the peer
>> doesn't
>> already have the tool in question, i.e. the kselftest "package" is also
>> installed
>> there.
>
> https://github.com/torvalds/linux/blob/master/Documentation/dev-tools/kselftest.rst#install-selftests
>
> does talk about installing the self tests. Maybe somewhere in
> /usr/local/libexec or /usr/local/bin.
Yep that's what I meant, this is what buildroot uses to populate the rootfs on
the target
Maxime
