Allow to read the carrier status of a netdevsim device via ethtool, like
most of Ethernet devices allow.

Also, allow to set its carrier status via sysfs. Currently it's only
possible by linking a peer device and setting its admin state to
UP/DOWN. By editing the carrier status via sysfs tests that need to
check carrier related stuff may be simpler.

The third patch add the proper selftest for both things, and the fourth
and fifth fix a few small bugs in the selftest itself.

Filip Pokryvka (1):
  netdevsim: Add ethtool get_link support

Íñigo Huguet (4):
  netdevsim: allow changing carrier state via sysfs
  selftest: netdevsim: test carrier change via sysfs
  selftest: netdevsim: cleanup the devices and module on failure
  selftest: netdevsim: suppress socat warnings

 drivers/net/netdevsim/ethtool.c               |  1 +
 drivers/net/netdevsim/netdev.c                | 23 +++++
 .../selftests/drivers/net/netdevsim/peer.sh   | 84 ++++++++++++-------
 3 files changed, 80 insertions(+), 28 deletions(-)

-- 
2.53.0

On Sun, 10 May 2026 18:43:32 +0200 Íñigo Huguet wrote:
> Allow to read the carrier status of a netdevsim device via ethtool, like
> most of Ethernet devices allow.
> 
> Also, allow to set its carrier status via sysfs. Currently it's only
> possible by linking a peer device and setting its admin state to
> UP/DOWN. By editing the carrier status via sysfs tests that need to
> check carrier related stuff may be simpler.
> 
> The third patch add the proper selftest for both things, and the fourth
> and fifth fix a few small bugs in the selftest itself.

Could you please explain your motivation? Feels quite trivial,
so it's not immediately obvious why we need tests.

Hi Jakub,

On Sun, May 10, 2026 at 6:52 PM Jakub Kicinski <kuba@kernel.org> wrote:
> Could you please explain your motivation? Feels quite trivial,
> so it's not immediately obvious why we need tests.
>

We use netdevsim for some userspace CI testing here at Red Hat. Specifically,
There are some tests that require reacting to carrier changes on a device
matched by permanent MAC address from userspace. As veths don't have a
permanent MAC address, we need netdevsim for this test case.

As you say, it's pretty trivial, but IMHO there's nothing against it, as it
will help to resemble better a typical Ethernet device.

Note: we know that there's no guarantee regarding netdevsim's uAPI and we're
ready to adapt for any change, but the truth is that there's no reasonable
replacement of netdevsim for these kinds of cases where veth is not enough.



-- 
Íñigo Huguet

On Mon, 11 May 2026 11:50:32 +0200 Íñigo Huguet wrote:
> On Sun, May 10, 2026 at 6:52 PM Jakub Kicinski <kuba@kernel.org> wrote:
> > Could you please explain your motivation? Feels quite trivial,
> > so it's not immediately obvious why we need tests.
> >  
> 
> We use netdevsim for some userspace CI testing here at Red Hat. Specifically,
> There are some tests that require reacting to carrier changes on a device
> matched by permanent MAC address from userspace. As veths don't have a
> permanent MAC address, we need netdevsim for this test case.
> 
> As you say, it's pretty trivial, but IMHO there's nothing against it, as it
> will help to resemble better a typical Ethernet device.
> 
> Note: we know that there's no guarantee regarding netdevsim's uAPI and we're
> ready to adapt for any change, but the truth is that there's no reasonable
> replacement of netdevsim for these kinds of cases where veth is not enough.

All code require maintenance. I'm trying to push back on netdevsim use
across the board. It was essentially a workaround for us not having any
real HW CI upstream. But that's no longer the case. Well, we still don't
have any crypto-capable HW :/ I think you'd be better off implementing
whatever you need in a small OOT module instead adding fake tests
upstream.

On Tue, May 12, 2026 at 1:59 AM Jakub Kicinski <kuba@kernel.org> wrote:
> All code require maintenance. I'm trying to push back on netdevsim use
> across the board. It was essentially a workaround for us not having any
> real HW CI upstream. But that's no longer the case. Well, we still don't
> have any crypto-capable HW :/ I think you'd be better off implementing
> whatever you need in a small OOT module instead adding fake tests
> upstream.

OK, we'll continue with our current approach of maintaining some OOT
patches and recompile netdevsim with them.

However, just as an opinion to consider: I don't think that pushing back on
netdevsim is good. Even if you (upstream Linux) have available hardware
now, small distributions may not have it. And userspace projects that
interact with the Linux uAPI may not have it. But they can still benefit from a
mocked Ethernet device like netdevsim to have a decent CI coverage, which
benefits the entire Linux ecosystem's quality.

For these userspace projects, saying that they should create their own OOT
module (basically reinventing part of netdevsim) is not reasonable. They may
not have enough kernel knowledge, and the effort is absolutely not worth it.
They will just probably leave some parts without testing coverage.

A better alternative would be to have a common OOT module that many
projects can share and use. But that common module already exists: netdevsim.
And it's hosted in its natural place: upstream kernel.

Those are my 2 cents. Thanks for your time and feedback, OTOH I totally
understand your concerns about the effort required to maintain any piece of
code.

-- 
Íñigo Huguet