Re: [PATCH net-next v2 0/2] selftests: drv-net: Allow cross-compiling the hardware tests

[Maxime Chevallier]

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