linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vincent Whitchurch <vincent.whitchurch@axis.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kernel <kernel@axis.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-um@lists.infradead.org" <linux-um@lists.infradead.org>,
	"shuah@kernel.org" <shuah@kernel.org>,
	"brendanhiggins@google.com" <brendanhiggins@google.com>,
	"linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"a.zummo@towertech.it" <a.zummo@towertech.it>,
	"alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>,
	"linux-rtc@vger.kernel.org" <linux-rtc@vger.kernel.org>,
	"corbet@lwn.net" <corbet@lwn.net>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Subject: Re: [RFC v1 08/10] iio: light: vcnl4000: add roadtest
Date: Tue, 5 Apr 2022 15:48:05 +0200	[thread overview]
Message-ID: <20220405134805.GA28574@axis.com> (raw)
In-Reply-To: <20220320170253.5b946c84@jic23-huawei>

On Sun, Mar 20, 2022 at 06:02:53PM +0100, Jonathan Cameron wrote:
> Very interesting bit of work. My current approach for similar testing
> is to write a qemu model for the hardware, but that currently
> requires carefully crafted tests. Most of the time I'm only doing
> that to verify refactoring of existing drivers. 

Thank you for taking a look!

> One thing that makes me nervous here is the python element though
> as I've not written significant python in about 20 years.
> That is going to be a burden for kernel developers and maintainers...
> Nothing quite like badly written tests to make for a mess in the long run
> and I suspect my python for example would be very very badly written :)

There's a bunch of static checkers to ensure that the code follows some
basic guidelines, and CI can check that the tests work consistently, and
also calculate metrics such as test execution time and code coverage, so
even non-idiomatic Python in the tests wouldn't be entirely broken.

And unlike driver code, if the tests for a particular driver later do
turn out to be bad (in what way?), we could just throw those particular
tests out without breaking anybody's system.

> Cut and paste will of course get us a long way...

Isn't some amount of copy/paste followed by modification to be expected
even if the framework is written in say C (just as there's already
copy/paste + modification involved when writing drivers)?

As for the core logic of individual driver tests excluding the framework
bits, I have a hard time imagining what Python syntax looks like to
someone with no knowledge of Python, so yes, I guess it's going to be
harder to review.

> I dream of a world where every driver is testable by people with out hardware
> but I fear it may be a while yet.  Hopefully this will get us a little
> closer!
> 
> I more or less follow what is going on here (good docs btw in the earlier
> patch definitely helped).
> 
> So far I'm thoroughly in favour of road test subject to actually being
> able to review the tests or getting sufficient support to do so.
> It's a 'how to scale it' question really...

Would rewriting the framework in C and forcing tests to be written in
that language mean that maintainers would be able to review tests
without external support?

  reply	other threads:[~2022-04-05 22:56 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-11 16:24 [RFC v1 00/10] roadtest: a driver testing framework Vincent Whitchurch
2022-03-11 16:24 ` [RFC v1 01/10] roadtest: import libvhost-user from QEMU Vincent Whitchurch
2022-03-24 13:00   ` Johannes Berg
2022-04-05 13:54     ` Vincent Whitchurch
2022-03-11 16:24 ` [RFC v1 02/10] roadtest: add C backend Vincent Whitchurch
2022-03-11 16:24 ` [RFC v1 03/10] roadtest: add framework Vincent Whitchurch
2022-03-11 16:24 ` [RFC v1 04/10] roadtest: add base config Vincent Whitchurch
2022-03-11 16:24 ` [RFC v1 05/10] roadtest: add build files Vincent Whitchurch
2022-03-11 16:24 ` [RFC v1 06/10] roadtest: add documentation Vincent Whitchurch
2022-03-11 16:24 ` [RFC v1 07/10] iio: light: opt3001: add roadtest Vincent Whitchurch
2022-03-14 23:11   ` Brendan Higgins
2022-03-18 15:49     ` Vincent Whitchurch
2022-03-18 20:09       ` Johannes Berg
2022-03-29 14:43         ` Vincent Whitchurch
2022-03-29 14:50           ` Johannes Berg
2022-03-29 14:52             ` Johannes Berg
2022-03-11 16:24 ` [RFC v1 08/10] iio: light: vcnl4000: " Vincent Whitchurch
2022-03-20 17:02   ` Jonathan Cameron
2022-04-05 13:48     ` Vincent Whitchurch [this message]
2022-04-06 13:08       ` Jonathan Cameron
2022-04-14 10:20         ` Vincent Whitchurch
2022-03-11 16:24 ` [RFC v1 09/10] regulator: tps62864: " Vincent Whitchurch
2022-03-11 18:06   ` Mark Brown
2022-03-17 15:13     ` Vincent Whitchurch
2022-03-17 17:53       ` Mark Brown
2022-04-05 14:02         ` Vincent Whitchurch
2022-03-11 16:24 ` [RFC v1 10/10] rtc: pcf8563: " Vincent Whitchurch
2022-03-14 22:24 ` [RFC v1 00/10] roadtest: a driver testing framework Brendan Higgins
2022-03-17 16:09   ` Vincent Whitchurch
2022-04-18 19:44 ` Jonathan Cameron

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=20220405134805.GA28574@axis.com \
    --to=vincent.whitchurch@axis.com \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@bootlin.com \
    --cc=brendanhiggins@google.com \
    --cc=broonie@kernel.org \
    --cc=corbet@lwn.net \
    --cc=devicetree@vger.kernel.org \
    --cc=jic23@kernel.org \
    --cc=kernel@axis.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=linux-um@lists.infradead.org \
    --cc=shuah@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).