[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <70497ad83be1c7bd715abc8f29c72ee39a381f58.camel@redhat.com>
Date: Wed, 06 Dec 2023 16:13:59 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Petr Machata <petrm@...dia.com>
Cc: Hangbin Liu <liuhangbin@...il.com>, netdev@...r.kernel.org, "David S.
Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Eric
Dumazet <edumazet@...gle.com>, Shuah Khan <shuah@...nel.org>, David Ahern
<dsahern@...nel.org>, linux-kselftest@...r.kernel.org, Po-Hsu Lin
<po-hsu.lin@...onical.com>, Guillaume Nault <gnault@...hat.com>, James
Prestwood <prestwoj@...il.com>, Jaehee Park <jhpark1013@...il.com>, Ido
Schimmel <idosch@...dia.com>, Justin Iurman <justin.iurman@...ege.be>, Xin
Long <lucien.xin@...il.com>, James Chapman <jchapman@...alix.com>
Subject: Re: [PATCHv3 net-next 01/14] selftests/net: add lib.sh
On Wed, 2023-12-06 at 13:32 +0100, Petr Machata wrote:
> Paolo Abeni <pabeni@...hat.com> writes:
>
> > Side note for a possible follow-up: if you maintain $ns_list as global
> > variable, and remove from such list the ns deleted by cleanup_ns, you
> > could remove the cleanup trap from the individual test with something
> > alike:
> >
> > final_cleanup_ns()
> > {
> > cleanup_ns $ns_list
> > }
> >
> > trap final_cleanup_ns EXIT
> >
> > No respin needed for the above, could be a follow-up if agreed upon.
>
> If you propose this for the library then I'm against it. The exit trap
> is a global resource that the client scripts sometimes need to use as
> well, to do topology teardowns or just general cleanups.
> So either the library would have to provide APIs for cleanup management, or the trap
> is for exclusive use by clients. The latter is IMHO simpler.
Even the former would not be very complex:
TRAPS=""
do_at_exit() {
TRAPS="${TRAPS}$@;"
trap "${TRAPS}" EXIT
}
And then use "do_at_exit <whatever>" instead of "trap <whatever> EXIT"
> It also puts the cleanups at the same place where the acquisition is
> prompted: the client allocates the NS, the client should prompt its
> cleanup.
I guess I could argue that the the script is asking the library to
allocate the namespaces, and the library could take care of disposing
them.
But I'm not pushing the proposed option, if there is no agreement no
need for additional work ;)
Cheers,
Paolo
Powered by blists - more mailing lists