From: Jani Nikula <jani.nikula@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>,
Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Cc: igt-dev@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH i-g-t 1/1] tests: Remove tools_test
Date: Fri, 14 Sep 2018 16:27:14 +0300 [thread overview]
Message-ID: <875zz8yzt9.fsf@intel.com> (raw)
In-Reply-To: <20180914092814.GN11082@phenom.ffwll.local>
On Fri, 14 Sep 2018, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Sep 12, 2018 at 09:56:24AM +0300, Arkadiusz Hiler wrote:
>> On Wed, Sep 12, 2018 at 09:51:24AM +0300, Petri Latvala wrote:
>> > The test is basically just testing if the tools work properly with
>> > little relevance to testing if the kernel works properly. If the
>> > purpose was to test the kernel (or hardware), actual tests will be
>> > better suited for the purpose. If the purpose was to test if the tools
>> > work, sanity checks somewhere else for all tools instead of just two
>> > is better suited for the purpose.
>> >
>> > In a nutshell, tools_test as such is fairly useless and has thus far
>> > only revealed problems in testing setups (incorrect paths etc) instead
>> > of problems in kernel or hardware.
>> >
>> > Signed-off-by: Petri Latvala <petri.latvala@intel.com>
>> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>> > Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
>> Acked-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
>
> Hm, not terribly happy about this. We have blown up the tools in trivial
> ways before, that's why I wrote these. And yes it's incomplete coverage.
> But we're also not going around deleting other igt tests, just because
> they're not yet fully covering a given area.
I think there's value in ensuring we don't break the tools from an ABI
perspective. But at the same time I don't think we need to test the
tools for every patch posted on the list. I.e. tool testing should be
separated from ABI testing.
So here's an idea. Extend the tools with a test subcommand or --test
parameter, and have the tools themselves check that the ABI they need
works. Centralize that information in the tools.
For example, 'intel_reg dump' is a ridiculously slow and potentially
dangerous way to test if intel_reg works. I've overlooked that in
tools_test; I would never have added something like that in intel_reg.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
next prev parent reply other threads:[~2018-09-14 13:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-12 6:51 [igt-dev] [PATCH i-g-t 1/1] tests: Remove tools_test Petri Latvala
2018-09-12 6:56 ` Arkadiusz Hiler
2018-09-14 9:28 ` Daniel Vetter
2018-09-14 13:27 ` Jani Nikula [this message]
2018-09-14 15:26 ` Daniel Vetter
2018-09-12 8:12 ` [igt-dev] ✓ Fi.CI.BAT: success for series starting with [i-g-t,1/1] " Patchwork
2018-09-12 10:13 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
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=875zz8yzt9.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=arkadiusz.hiler@intel.com \
--cc=daniel@ffwll.ch \
--cc=igt-dev@lists.freedesktop.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