All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rae Moar <rmoar@google.com>
To: Daniel Latypov <dlatypov@google.com>
Cc: shuah@kernel.org, davidgow@google.com, brendan.higgins@linux.dev,
	 kevko@google.com, linux-kselftest@vger.kernel.org,
	kunit-dev@googlegroups.com,  linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kunit: tool: add parsing of all files in directory
Date: Tue, 27 Feb 2024 14:41:05 -0500	[thread overview]
Message-ID: <CA+GJov5hCde3JAuwdZayzQ0HUkexbtgAVFrXbDeqpufV6OdC3g@mail.gmail.com> (raw)
In-Reply-To: <CAGS_qxqQ09wUppF9s1BgNoj5T2yo8+Yd0RLRBisj5th7Yw97eQ@mail.gmail.com>

On Thu, Feb 22, 2024 at 6:37 PM Daniel Latypov <dlatypov@google.com> wrote:
>
> On Thu, Feb 22, 2024 at 2:18 PM Rae Moar <rmoar@google.com> wrote:
> >
> > Add ability to parse all files within a directory. Additionally add the
> > ability to parse all results in the KUnit debugfs repository.
>
> Nice, I'd been hoping for this.
> It's enough to pull me back in for a bit :)
>
> <snip>
>
> >  tools/testing/kunit/kunit.py | 45 ++++++++++++++++++++++++++----------
> >  1 file changed, 33 insertions(+), 12 deletions(-)
> >
> > diff --git a/tools/testing/kunit/kunit.py b/tools/testing/kunit/kunit.py
> > index bc74088c458a..827e6dac40ae 100755
> > --- a/tools/testing/kunit/kunit.py
> > +++ b/tools/testing/kunit/kunit.py
> > @@ -511,19 +511,40 @@ def exec_handler(cli_args: argparse.Namespace) -> None:
> >
> >
> >  def parse_handler(cli_args: argparse.Namespace) -> None:
> > -       if cli_args.file is None:
> > +       parsed_files = []
>
> optional: can we annotate the type?
>   parsed_files = []  # type: List[str]

Hi Daniel!

Yes, happy to make this change for the next version.

>
> > +       total_test = kunit_parser.Test()
> > +       total_test.status = kunit_parser.TestStatus.SUCCESS
> > +       if cli_args.file_path is None:
> >                 sys.stdin.reconfigure(errors='backslashreplace')  # type: ignore
> >                 kunit_output = sys.stdin  # type: Iterable[str]
>
> This branch no longer does anything, since we only parse what's in
> `parsed_files`
>
> E.g. if you try
> $ kunit.py parse $FILENAME
> it'll work whereas
> $ kunit.py parse < $FILENAME
> will do nothing
>
> We'll need to rework the control flow somehow

Ahh I see. Thanks for bringing this to my attention! I will change
this for the next version.

>
> > -       else:
> > -               with open(cli_args.file, 'r', errors='backslashreplace') as f:
> > +       elif cli_args.file_path == "debugfs":
> > +               for (root, _, files) in os.walk("/sys/kernel/debug/kunit"):
> > +                       for file in files:
> > +                               if file == "results":
> > +                                       parsed_files.append(os.path.join(root, file))
> > +       elif os.path.isdir(cli_args.file_path):
> > +               for (root, _, files) in os.walk(cli_args.file_path):
> > +                       for file in files:
> > +                               parsed_files.append(os.path.join(root, file))
>
> just a note here, we could make this a bit terser via
>   parsed_files.extend(os.path.join(root, f) for f in files)
>
> and the debugfs branch could be rendered as
>   parsed_files.extend(os.path.join(root, f) for f in files if f == "results")
>

Will do.

> > +       elif os.path.isfile(cli_args.file_path):
> > +               parsed_files.append(cli_args.file_path)
>
> nit: should there be an `else` here that prints a warning?
>
> Example that would trigger this case and silently do nothing
> $ mkfifo /tmp/example_fifo
> $ ./tools/testing/kunit/kunit.py parse /tmp/example_fifo
> <no output>
>

Yep you are definitely right I will add one here.

>
> <snip>
>
> > @@ -569,8 +590,8 @@ def main(argv: Sequence[str]) -> None:
> >                                             help='Parses KUnit results from a file, '
> >                                             'and parses formatted results.')
> >         add_parse_opts(parse_parser)
> > -       parse_parser.add_argument('file',
> > -                                 help='Specifies the file to read results from.',
> > +       parse_parser.add_argument('file_path',
> > +                                 help='Specifies the file path to read results from.',
>
> Should this mention that the make `debugfs` string works?
>
> >                                   type=str, nargs='?', metavar='input_file')
>
> Tangent: would it be useful to allow the user to pass in multiple
> files now and set this to nargs='*'?
>
> E.g.
> $ kunit.py parse /my/dir/some_prefix*
>
> It would also let people implement their own version of the debugfs logic via
> $ find /other/debugfs/dir -name 'results' | xargs kunit.py parse
>
> That could be useful if the user has recursively copied off the
> debugfs from a test machine and wants to inspect it elsewhere, for
> example.
>

Oh this is an interesting idea. I will play around with it!

Thanks for looking this patch over!
-Rae

> Thanks,
> Daniel

      reply	other threads:[~2024-02-27 19:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-22 22:18 [PATCH] kunit: tool: add parsing of all files in directory Rae Moar
2024-02-22 23:37 ` Daniel Latypov
2024-02-27 19:41   ` Rae Moar [this message]

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=CA+GJov5hCde3JAuwdZayzQ0HUkexbtgAVFrXbDeqpufV6OdC3g@mail.gmail.com \
    --to=rmoar@google.com \
    --cc=brendan.higgins@linux.dev \
    --cc=davidgow@google.com \
    --cc=dlatypov@google.com \
    --cc=kevko@google.com \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.