[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230824084934.3b9b96ee@kernel.org>
Date: Thu, 24 Aug 2023 08:49:34 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: "Michalik, Michal" <michal.michalik@...el.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"vadim.fedorenko@...ux.dev" <vadim.fedorenko@...ux.dev>, "jiri@...nulli.us"
<jiri@...nulli.us>, "Kubalewski, Arkadiusz"
<arkadiusz.kubalewski@...el.com>, "jonathan.lemon@...il.com"
<jonathan.lemon@...il.com>, "pabeni@...hat.com" <pabeni@...hat.com>, poros
<poros@...hat.com>, "Olech, Milena" <milena.olech@...el.com>, mschmidt
<mschmidt@...hat.com>, "linux-clk@...r.kernel.org"
<linux-clk@...r.kernel.org>, "bvanassche@....org" <bvanassche@....org>
Subject: Re: [PATCH RFC net-next v1 2/2] selftests/dpll: add DPLL system
integration selftests
On Thu, 24 Aug 2023 08:59:53 +0000 Michalik, Michal wrote:
> >> The biggest concern for me is the requirement of selftests[2]:
> >> "Don't take too long;"
> >> This approach is reloading the modules few times to check few scenarios.
> >> Also, the DPLL subsystem is being tested against multiple requests - so
> >> it takes some time to finish (not too long but is definitely not instant).
> >
> > I think the time constraints are more of a question of practicality.
> > A developer should be able to run the tests as part of their workflow.
>
> That makes sense - agree. So Jakub, if I understand correctly we have a few
> different problems to solve here:
> 1) how to deploy the module:
> - now it's separated, we should consider e.g. netdevsim
> 2) if we should have those tests a part of selftests
> - I would remove it from selftests and move it to ./tools/testing
> 3) if we should use Python at all:
> - fast to develop and easy to maintain
> - might be problematic to deploy (no Python, VMs, embedded, no network etc.)
>
> Do I understand our current outcome of the discussion correctly?
Yes, and on (3) unless someone objects let's stick to Python.
Powered by blists - more mailing lists