From: Petr Machata <petrm@nvidia.com>
To: Ioana Ciornei <ioana.ciornei@nxp.com>
Cc: Petr Machata <petrm@nvidia.com>, <netdev@vger.kernel.org>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>, <linux-kernel@vger.kernel.org>,
<willemb@google.com>, <linux-kselftest@vger.kernel.org>
Subject: Re: [PATCH net-next v4 02/10] selftests: net: add helpers for running a command on other targets
Date: Mon, 30 Mar 2026 16:55:52 +0200 [thread overview]
Message-ID: <877bqt4afo.fsf@nvidia.com> (raw)
In-Reply-To: <mmr6xs4soark6ilc2xymgcvn3wij2yoaeokpuv5i62mxtddvpa@jdyswkdydpon>
Ioana Ciornei <ioana.ciornei@nxp.com> writes:
> On Mon, Mar 30, 2026 at 01:32:41PM +0200, Petr Machata wrote:
>>
>> Petr Machata <petrm@nvidia.com> writes:
>>
>> > Ioana Ciornei <ioana.ciornei@nxp.com> writes:
>> >
>> >> +run_on()
>> >> +{
>> >> + local iface=$1; shift
>> >> + local target="local:"
>> >> +
>> >> + if declare -p TARGETS &>/dev/null; then
>> >> + target="${TARGETS[$iface]}"
>> >
>> > So I think Jakub's runs fail because there's a shell export somewhere
>> > that gets inherited through make to the launched test. I guess it would
>> > be enough for the test to validate that TARGETS is an array, because
>> > those don't get inherited.
>> >
>> > Is there a reason not to reuse DRIVER_TEST_CONFORMANT as a tell though?
>> >
>> >> + fi
>> >> +
>> >> + __run_on "$target" "$@"
>> >> +}
>> >
>> > Does the latter helper need to be in net/lib.sh? Since it uses TARGETS,
>> > which are a forwarding/lib.sh concept, it seems misplaced there.
>>
>> Oh, I see, there's an invocation from mac_get() in net/lib.sh itself.
>> Hummm. Not sure how to tackle this.
>>
>> I think lib.sh might unset TARGETS explicitly? Or declare -A, but leave
>> empty? Since it's now an API, net/lib.sh needs to set it to a reasonable
>> value (or erase). Then forwarding/lib.sh might in theory rely on
>> existence of that variable and not have to declare it at all.
>>
>> Or, maybe have a stub run_on() like this to satisfy the run_on() API:
>>
>> run_on()
>> {
>> "$@"
>
> shift; "$@"
Indeed!
>> }
>>
>> And have the full-blown thing in forward/lib.sh. All the magic with
>> TARGETS really belongs to forwarding/lib.sh. Bash allows function
>> redefinition just fine, so a user importing just net/lib.sh would get
>> the stub, and forwarding/lib.sh users would get the full thing.
>
> I really like the idea of the stub run_on() in net/lib.sh. This would
> also give me the possibility to check for DRIVER_TEST_CONFORMANT = "yes"
> in the full-blown run_on() without having to move its default
> definition in net/lib.sh.
>
> I quickly changed to this approach and it seems to look good.
Yeah, I like it best as well.
Then I think you don't need to worry about the TARGETS export, because
forwarding/lib.sh will add the "array-ness" to whatever comes from the
outside, if anything, and the function will be able to use like that.
next prev parent reply other threads:[~2026-03-30 15:14 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-26 13:28 [PATCH net-next v4 00/10] selftests: drivers: bash support for remote traffic generators Ioana Ciornei
2026-03-26 13:28 ` [PATCH net-next v4 01/10] selftests: forwarding: extend ethtool_std_stats_get with pause statistics Ioana Ciornei
2026-03-26 13:28 ` [PATCH net-next v4 02/10] selftests: net: add helpers for running a command on other targets Ioana Ciornei
2026-03-30 11:02 ` Petr Machata
2026-03-30 11:32 ` Petr Machata
2026-03-30 12:12 ` Ioana Ciornei
2026-03-30 14:55 ` Petr Machata [this message]
2026-03-31 0:04 ` Jakub Kicinski
2026-03-31 11:53 ` Petr Machata
2026-03-26 13:28 ` [PATCH net-next v4 03/10] selftests: net: extend lib.sh to parse drivers/net/net.config Ioana Ciornei
2026-03-30 11:28 ` Petr Machata
2026-03-30 12:28 ` Ioana Ciornei
2026-03-26 13:28 ` [PATCH net-next v4 04/10] selftests: net: update some helpers to use run_on Ioana Ciornei
2026-03-30 11:55 ` Petr Machata
2026-03-26 13:28 ` [PATCH net-next v4 05/10] selftests: drivers: hw: cleanup shellcheck warnings in the rmon test Ioana Ciornei
2026-03-26 13:28 ` [PATCH net-next v4 06/10] selftests: drivers: hw: test rmon counters only on first interface Ioana Ciornei
2026-03-26 13:28 ` [PATCH net-next v4 07/10] selftests: drivers: hw: replace counter upper limit with UINT32_MAX in rmon test Ioana Ciornei
2026-03-26 13:28 ` [PATCH net-next v4 08/10] selftests: drivers: hw: move to KTAP output Ioana Ciornei
2026-03-30 12:01 ` Petr Machata
2026-03-26 13:28 ` [PATCH net-next v4 09/10] selftests: drivers: hw: update ethtool_rmon to work with a single local interface Ioana Ciornei
2026-03-26 13:28 ` [PATCH net-next v4 10/10] selftests: drivers: hw: add test for the ethtool standard counters Ioana Ciornei
2026-03-30 12:03 ` Petr Machata
2026-03-26 19:03 ` [PATCH net-next v4 00/10] selftests: drivers: bash support for remote traffic generators Jakub Kicinski
2026-03-27 7:32 ` Ioana Ciornei
2026-03-28 0:24 ` Jakub Kicinski
2026-03-30 10:38 ` Petr Machata
2026-03-30 11:10 ` Petr Machata
2026-03-30 11:11 ` Ioana Ciornei
2026-03-30 11:52 ` Petr Machata
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877bqt4afo.fsf@nvidia.com \
--to=petrm@nvidia.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=ioana.ciornei@nxp.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=willemb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.