[Intel-gfx] [PATCH i-g-t v2] tests/gem_flink_basic: Add documentation for subtests
Arkadiusz Hiler
arkadiusz.hiler at intel.com
Thu Sep 7 12:37:39 UTC 2017
On Tue, Sep 05, 2017 at 05:04:35PM -0700, Belgaumkar, Vinay wrote:
>
>
> On 9/1/2017 4:55 AM, Arkadiusz Hiler wrote:
> > On Thu, Aug 31, 2017 at 02:33:23PM -0700, Vinay Belgaumkar wrote:
> > > Added the missing IGT_TEST_DESCRIPTION and some subtest
> > > descriptions. Trying to establish a method to document
> >
> > Hey Vinay,
> >
> > Please add appropriate tag to the subject, as this is clearly an RFC.
> >
> > > subtests, it should describe the feature being tested
> > > rather than how. The HOW part can, if needed, be
> > > described in the test code.
> > >
> > > Documenting subtests will give us a good way to trace
> > > feature test coverage, and also help a faster ramp
> > > for understanding the test code.
> > >
> > > v2: Removed duplication, addressed comments, cc'd test author
> > >
> > > Cc: Michał Winiarski <michal.winiarski at intel.com>
> > > Cc: Eric Anholt <eric at anholt.net>
> > >
> > > Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar at intel.com>
> > > ---
> > > tests/gem_flink_basic.c | 36 ++++++++++++++++++++++++++----------
> > > 1 file changed, 26 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/tests/gem_flink_basic.c b/tests/gem_flink_basic.c
> > > index 26ae7d6..9c8c4c3 100644
> > > --- a/tests/gem_flink_basic.c
> > > +++ b/tests/gem_flink_basic.c
> > > @@ -36,6 +36,8 @@
> > > #include <sys/ioctl.h>
> > > #include "drm.h"
> > >
> > > +IGT_TEST_DESCRIPTION("Tests for flink - a way to export a gem object by name");
> > > +
> > > static void
> > > test_flink(int fd)
> > > {
> > > @@ -44,8 +46,6 @@ test_flink(int fd)
> > > struct drm_gem_open open_struct;
> > > int ret;
> > >
> > > - igt_info("Testing flink and open.\n");
> > > -
> > > memset(&create, 0, sizeof(create));
> > > create.size = 16 * 1024;
> > > ret = ioctl(fd, DRM_IOCTL_I915_GEM_CREATE, &create);
> > > @@ -69,8 +69,6 @@ test_double_flink(int fd)
> > > struct drm_gem_flink flink2;
> > > int ret;
> > >
> > > - igt_info("Testing repeated flink.\n");
> > > -
> > > memset(&create, 0, sizeof(create));
> > > create.size = 16 * 1024;
> > > ret = ioctl(fd, DRM_IOCTL_I915_GEM_CREATE, &create);
> > > @@ -92,8 +90,6 @@ test_bad_flink(int fd)
> > > struct drm_gem_flink flink;
> > > int ret;
> > >
> > > - igt_info("Testing error return on bad flink ioctl.\n");
> > > -
> > > flink.handle = 0x10101010;
> > > ret = ioctl(fd, DRM_IOCTL_GEM_FLINK, &flink);
> > > igt_assert(ret == -1 && errno == ENOENT);
> > > @@ -105,8 +101,6 @@ test_bad_open(int fd)
> > > struct drm_gem_open open_struct;
> > > int ret;
> > >
> > > - igt_info("Testing error return on bad open ioctl.\n");
> > > -
> > > open_struct.name = 0x10101010;
> > > ret = ioctl(fd, DRM_IOCTL_GEM_OPEN, &open_struct);
> > >
> > > @@ -121,8 +115,6 @@ test_flink_lifetime(int fd)
> > > struct drm_gem_open open_struct;
> > > int ret, fd2;
> > >
> > > - igt_info("Testing flink lifetime.\n");
> > > -
> > > fd2 = drm_open_driver(DRIVER_INTEL);
> > >
> > > memset(&create, 0, sizeof(create));
> > > @@ -134,11 +126,13 @@ test_flink_lifetime(int fd)
> > > ret = ioctl(fd2, DRM_IOCTL_GEM_FLINK, &flink);
> > > igt_assert_eq(ret, 0);
> > >
> > > + /* Open another reference to the gem object */
> > > open_struct.name = flink.name;
> > > ret = ioctl(fd, DRM_IOCTL_GEM_OPEN, &open_struct);
> > > igt_assert_eq(ret, 0);
> > > igt_assert(open_struct.handle != 0);
> > >
> > > + /* Before closing the previous one */
> > > close(fd2);
> > > fd2 = drm_open_driver(DRIVER_INTEL);
> > >
> > > @@ -155,14 +149,36 @@ igt_main
> > > igt_fixture
> > > fd = drm_open_driver(DRIVER_INTEL);
> > >
> > > + /**
> > > + * basic:
> >
> > Much better than the previous proposal.
> >
> > But I do not like having the subtest name twice - in the comment and in
> > the igt_subtest().
> >
> > IMO it's better to have a parser that can extract the name from the
> > following igt_subtest() than having a place where when we have
> > duplication and we can go out of sync.
>
> Agreed. If the new documentation tool can support parsing of igt_subtest,
> then we do not need this. Although, when someone tries to rearrange code, it
> might prove useful to have the name of the subtest to which the
> documentation belongs.
Nope. Redundancy works in very few cases. Changes like those you've
mentioned should be easy to catch in a review. I don't see that as
enough of a justification.
> > I've been following your efforts and I have some question and thoughts
> > to share.
> >
> > ### Questions
> >
> > 1. What's the actual problem statement? What are you trying to solve
> > here?
>
> Subtests do not have documentation, I am trying to add that.
That's not a problem statement with a proposed solution.
That's having the documentation for the sake of having documentation.
"I want to paint walls blue because they are not blue".
I was expecting (basing on your past replies) something like:
"A lot of tests are hard to understand. We want to make them easier to
digest by adding comments on the unclear parts."
Was I wrong? Is it actually about having a documentation just for the
sake of it?
Having clear goals for documentation should help to come up with
solution meeting them.
> > 2. Who, in your mind, is the supposed reader of the documentation?
> > How's that different form someone who is supposed to look at the
> > code directly?
>
> Test/kernel developers and anyone who uses these tests.
So basically "everyone".
What would they expect from the documentation and why?
How is "test runner" different form "kernel developer"?
IMHO it's very important to have understanding who is the intended
reader of the documentation, how tech-savvy they are, what they may
expect and how capable they are using complementary sources of
information.
> > 3. Why are you trying to drive this? What's your motivation?
>
> Our team is moving to use IGT instead of our internal test framework. We
> think it will be easier for folks to ramp up on these tests if there was
> sufficient documentation.
Looking forward to seeing more contributions from the team in the future
then :-)
> > ### My Two (Euro)cents
> >
> > As Michal stressed, in a reply to the previous revision, we should not
> > be doing C to English translation. My reasoning:
> >
> > 1. Maintenance hell - if you describe inner workings of tests in too
> > much detail, you will have two places that you have to update when you
> > are making even the slightest adjustments.
> >
> > And people will forget to update the comments, and will receive negative
> > reviews, and will have to respin the series making the changes again,
> > this time in the "English" implementation.
> >
> > To me it's unnecessary rising of the bar for the contributors.
> >
> > 2. Code is enough - I think it's safe to assume that anyone who is
> > enough technically inclined to understand the English translation of the
> > code will be able to understand the code itself.
> >
> > And the code is openly and freely available. So I do not see much use of
> > embedding it into the documentation.
> >
> > 3. The more manual tasks we have for the tests developers, the less
> > appealing the project is. If it will get unpleasant, the people will
> > think twice about contributing - and not to contribute better things,
> > but whether the chores are worth their time.
> >
>
> Not sure how I can convince that we need documentation apart from the usual
> advantages of improving code readability. As for maintenance, I have tried
> to make the description as short as possible. We already document APIs and
> code today, so it's not a big change that is being suggested.
But you do not have to convince me that IGTs can be hard to digest and
could use some good ol' documentation here and there.
I just want to ensure that we won't find ourselves knee deep in
unenforcible guidelines that impair development instead of accelerating
it and making it more friendly.
I just want to be realistic.
> > ### My Expectations
> >
> > Definitely we should improve IGT documentation and general readability.
> > But having too much documentation is even wore.
> >
> > 1. Subtest documentation should be as brief as possible and give you good
> > intuition on what it is exercising - for actual details people should
> > refer the source code.
>
> Agreed. My second version attempts to meet those goals.
> >
> > 2. It should not describe the "feature" it is testing, there are other
> > places to do that. It should just give enough of a context to be
> > understood by someone who has the general idea of the "feature".
>
> I tried that approach, but other opinions seem to suggest there is no point
> in describing what the test is doing, since the test code will elaborate on
> that anyways.
Not in depth. Just something that gives you a decent idea what is
happening, then you can dig into the code (or not).
> > 3. It should feel like an added value to the developers, not as a
> > unnecessary, manual chore.
>
> Agree.
>
> >
> > 4. It should feel natural - it should just take a single glance at the
> > surrounding code and developer should know what to do - how the
> > commenting is done, what style should be assumed. Many people do not
> > read guidelines, and the longer the file is, the less likely is that
> > someone will read it through. The guidelines should be simple, to the
> > point, statements, that are supposed by actual good examples.
> > It's also easier to get a good idea what to do when you are are pointed to
> > good code in the actual code base instead of some artificial example.
>
> The guidelines are the same as API documentation, so that should help.
>
> >
> > 5. Comments inside the tests should be "the last resort", if the code
> > could not be rewritten easily in more readable manner. Their main
> > purpose is to help people reading code understand non-obvious parts.
> > This should be enforced by reviewers - if it takes you too long to
> > understand something, comment on that, possibly with suggested
> > rewrite/proposition of a comment.
>
> I would argue that anybody looking at test code for the first time would try
> and find some form of documentation about it. You can write code in a very
> lucid manner, but given the feature complexities, some form of feature
> description is definitely helpful.
Yes, but only when giving additional context to the code. I am arguing
against full documentation of the features or facilities. That's the
kernel/PRMs/system_manual responsibility.
> > Looking forward to your reply!
--
Cheers,
Arek
More information about the Intel-gfx
mailing list