From: Daniel Latypov <dlatypov@google.com>
To: Rae Moar <rmoar@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 v2] kunit: tool: add ability to parse multiple files
Date: Wed, 6 Mar 2024 16:15:07 -0800 [thread overview]
Message-ID: <CAGS_qxoMbFQMGtddX0B25qkH5p3RDZLgJEYbFcPBtsDDoUN-2Q@mail.gmail.com> (raw)
In-Reply-To: <20240306223056.226518-1-rmoar@google.com>
On Wed, Mar 6, 2024 at 2:30 PM Rae Moar <rmoar@google.com> wrote:
>
Note: looks like there's two small bugs w/ the stdin codepath.
If both are addressed, it looks like stdin works again for me.
<snip>
> Changes since v1:
> - Annotate type of parsed_files
> - Add ability to input file name from stdin again
> - Make for loops a bit terser
> - Add no output warning
> - Change feature to take in multiple fields rather than a directory.
> Currently nonrecursive. Let me know if people would prefer this as
> recursive.
Just noting that I'd like to hear other's opinions on this.
I personally prefer the current approach.
I don't imagine there are going to be many nested directories of just
KTAP output files.
I.e. I'm assuming users would either be fine with
# just one dir w/ all KTAP outputs
$ kunit.py parse some_dir/*
# KTAP mixed in w/ other files, like we see in debugfs
$ find some_dir/ -name 'ktap_output' | xargs kunit.py parse
>
> tools/testing/kunit/kunit.py | 45 +++++++++++++++++++++++++-----------
> 1 file changed, 32 insertions(+), 13 deletions(-)
>
> diff --git a/tools/testing/kunit/kunit.py b/tools/testing/kunit/kunit.py
> index bc74088c458a..df804a118aa5 100755
> --- a/tools/testing/kunit/kunit.py
> +++ b/tools/testing/kunit/kunit.py
> @@ -511,19 +511,37 @@ def exec_handler(cli_args: argparse.Namespace) -> None:
>
>
> def parse_handler(cli_args: argparse.Namespace) -> None:
> - if cli_args.file is None:
> + parsed_files = [] # type: List[str]
> + total_test = kunit_parser.Test()
> + total_test.status = kunit_parser.TestStatus.SUCCESS
> + if cli_args.files is None:
> sys.stdin.reconfigure(errors='backslashreplace') # type: ignore
> - kunit_output = sys.stdin # type: Iterable[str]
> + parsed_files.append(sys.stdin)
> + elif cli_args.files[0] == "debugfs" and len(cli_args.files) == 1:
For me, the stdin branch doesn't get taken, i.e.
$ ./tools/testing/kunit/kunit.py parse
...
File "./tools/testing/kunit/kunit.py", line 520, in parse_handler
elif cli_args.files[0] == "debugfs" and len(cli_args.files) == 1:
~~~~~~~~~~~~~~^^^
IndexError: list index out of range
If unspecified, apparently `cli_args.files == []`, so we'd want to change it to
if not cli_args.files:
# stdin codepath
> + for (root, _, files) in os.walk("/sys/kernel/debug/kunit"):
> + parsed_files.extend(os.path.join(root, f) for f in files if f == "results")
> else:
> - with open(cli_args.file, 'r', errors='backslashreplace') as f:
> + parsed_files.extend(f for f in cli_args.files if os.path.isfile(f))
> +
> + if len(parsed_files) == 0:
> + print("No output found.")
This is what a user sees if they pass a dir in now
$ ./tools/testing/kunit/kunit.py parse tools/testing/kunit/test_data/
No output found.
I'm wondering if we should try to make the user's error more obvious.
E.g. we could add a list where `not os.path.isfile(f)` and print it like:
$ ./tools/testing/kunit/kunit.py parse tools/testing/kunit/test_data/
Ignoring 1 non-regular files: tools/testing/kunit/test_data/
No output found.
> +
> + for file in parsed_files:
> + print(file)
> + with open(file, 'r', errors='backslashreplace') as f:
In the stdin case, `file` here is already a File object and not a filename.
Note: mypy/pytype will complain since the type annotation says List[str]
kunit.py:520: error: Argument 1 to "append" of "list" has
incompatible type "TextIO"; expected "str"
Could do something like
parsed_files = [] # type: List[Union[str, TextIO]]
...
if isinstance(file, str):
print(file)
with open(file, 'r', errors='backslashreplace') as f:
kunit_output = f.read().splitlines()
else: # file is sys.stdin
kunit_output = file.read().splitlines()
With ^ and the change above to the `if`, seems like stdin works for me
$ echo "invalid" | ./tools/testing/kunit/kunit.py parse
$ ./tools/testing/kunit/kunit.py parse <
tools/testing/kunit/test_data/test_skip_tests.log
Thanks,
Daniel
prev parent reply other threads:[~2024-03-07 0:15 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-06 22:30 [PATCH v2] kunit: tool: add ability to parse multiple files Rae Moar
2024-03-07 0:15 ` Daniel Latypov [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=CAGS_qxoMbFQMGtddX0B25qkH5p3RDZLgJEYbFcPBtsDDoUN-2Q@mail.gmail.com \
--to=dlatypov@google.com \
--cc=brendan.higgins@linux.dev \
--cc=davidgow@google.com \
--cc=kevko@google.com \
--cc=kunit-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=rmoar@google.com \
--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).