From: Petri Latvala <adrinael@adrinael.net>
To: Kamil Konieczny <kamil.konieczny@linux.intel.com>,
Lucas De Marchi <lucas.demarchi@intel.com>,
igt-dev@lists.freedesktop.org,
Gustavo Sousa <gustavo.sousa@intel.com>,
Peter Senna Tschudin <peter.senna@linux.intel.com>,
Ryszard Knop <ryszard.knop@intel.com>
Subject: Re: [PATCH i-g-t v2 6/7] runner/settings: Serialize command line
Date: Wed, 29 Jan 2025 20:09:14 +0200 [thread overview]
Message-ID: <Z5puykM91cje2ki8@adrinael.net> (raw)
In-Reply-To: <20250129172348.x5osrkk4yocdmdpk@kamilkon-desk.igk.intel.com>
On Wed, Jan 29, 2025 at 06:23:48PM +0100, Kamil Konieczny wrote:
> Hi Lucas,
> On 2025-01-28 at 13:34:24 -0600, Lucas De Marchi wrote:
> > On Tue, Jan 28, 2025 at 07:37:44PM +0100, Kamil Konieczny wrote:
> > > Hi Lucas,
> > > On 2025-01-21 at 14:57:32 -0800, Lucas De Marchi wrote:
> > > > Serialize the command line to metadata.txt. The expected format in the
> > > > metadata.txt is like below:
> > > >
> > > > cmdline.argc : 6
> > > > cmdline.argv[0] : ./build/runner/igt_runner
> > > > cmdline.argv[1] : -o
> > >
> > > Sorry for late reponse but imho it should be saved for debugging
> > > purpose but not for reading this in metadata.txt, especially that
> > > this option '-o' is 'override existing results folder', so it
> > > should be used only once by igt_runner in setup phase but not for
> > > igt_resume.
> > >
> > > From igt_runner --help:
> > > -o, --overwrite If the results-path already exists, delete it
> >
> > if you are using -o it's just because you don't care about the previous
> > results and want to completely overwrite it.
> >
> > igt_resume doesn't have any option - it doesn't have a -o and it
> > basically does:
> >
> > "Load the settings from the state dir back into the settings struct"...
> > igt_resume will read it back and create the settings object.
> >
> > The results.json as architected in igt_runner discards everything and
> > is basically a conversion format from the state dir to a .json file at
> > the end of the execution.
> >
> > >
> > > imho we should save it into some different file and include it into
> > > results.json
> >
> > not sure I follow... metadata.txt has the details of how we are running
> > igt_runner and it's basically a dump of the settings object. I don't
> > follow what's the relation with the -o option you mentioned above.
> >
> > End goal is to have the value in the results.json, but I see no reason
> > why the intermediary state needs to be in a different file.
> >
> > Lucas De Marchi
>
> Well, what I try to comment on a commit description:
>
> > Serialize the command line to metadata.txt. [...]
>
> imho this should be written in setup.txt and setup.txt should be
> included in results.json There is no need for igt_runner options
> in metadata.txt, as it is used by igt_resume in shard re-runs
> after a reboot happens in a middle of testlist.
The command line in metadata.txt does no harm as it's just
informational text to be recorded in the final result. It's also
supposed to indeed be a direct dump of the settings object, and thus
should have the command line if that is to be put into the settings
object. But I suppose the pertinent question is: why does it need to
be put into the settings object? There's already things like uname.txt
and starttime.txt and whatnot, written outside of
metadata.txt. Consolidate miscellaneous info dumps to a single file?
Do that when serializing command line _somewhere_, or perhaps later?
I have no opinions to offer in any direction, just drive-by commenting
here...
--
Petri Latvala
next prev parent reply other threads:[~2025-01-29 18:09 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-21 22:57 [PATCH i-g-t v2 0/7] Add igt_runner's cmdline to results Lucas De Marchi
2025-01-21 22:57 ` [PATCH i-g-t v2 1/7] runner/settings: Deduplicate cleanup Lucas De Marchi
2025-01-22 10:50 ` Gustavo Sousa
2025-01-22 12:22 ` Peter Senna Tschudin
2025-01-21 22:57 ` [PATCH i-g-t v2 2/7] runner/settings: Use wrapper functions for each type Lucas De Marchi
2025-01-22 11:20 ` Gustavo Sousa
2025-01-23 6:07 ` Lucas De Marchi
2025-01-23 11:20 ` Gustavo Sousa
2025-01-22 12:21 ` Peter Senna Tschudin
2025-01-23 6:22 ` Lucas De Marchi
2025-01-21 22:57 ` [PATCH i-g-t v2 3/7] runner/settings: Drop extra strdup Lucas De Marchi
2025-01-22 11:34 ` Gustavo Sousa
2025-01-22 12:22 ` Peter Senna Tschudin
2025-01-23 6:23 ` Lucas De Marchi
2025-01-23 11:15 ` Gustavo Sousa
2025-01-21 22:57 ` [PATCH i-g-t v2 4/7] runner/settings: Fix code_coverage_script leak Lucas De Marchi
2025-01-22 11:37 ` Gustavo Sousa
2025-01-22 12:23 ` Peter Senna Tschudin
2025-01-21 22:57 ` [PATCH i-g-t v2 5/7] runner: Free settings at the end Lucas De Marchi
2025-01-22 11:46 ` Gustavo Sousa
2025-01-22 12:23 ` Peter Senna Tschudin
2025-01-23 6:28 ` Lucas De Marchi
2025-01-24 17:25 ` Lucas De Marchi
2025-01-21 22:57 ` [PATCH i-g-t v2 6/7] runner/settings: Serialize command line Lucas De Marchi
2025-01-22 12:25 ` Peter Senna Tschudin
2025-01-22 12:40 ` Gustavo Sousa
2025-01-22 18:16 ` Peter Senna Tschudin
2025-01-22 18:26 ` Gustavo Sousa
2025-01-22 18:35 ` Peter Senna Tschudin
2025-01-22 18:55 ` Gustavo Sousa
2025-01-23 6:43 ` Lucas De Marchi
2025-01-22 18:53 ` Peter Senna Tschudin
2025-01-28 18:37 ` Kamil Konieczny
2025-01-28 19:34 ` Lucas De Marchi
2025-01-29 17:23 ` Kamil Konieczny
2025-01-29 18:09 ` Petri Latvala [this message]
2025-01-29 20:29 ` Lucas De Marchi
2025-01-29 20:15 ` Lucas De Marchi
2025-01-21 22:57 ` [PATCH i-g-t v2 7/7] runner/resultgen: Add cmdline to results.json Lucas De Marchi
2025-01-22 12:25 ` Peter Senna Tschudin
2025-01-22 12:51 ` Gustavo Sousa
2025-01-23 6:50 ` Lucas De Marchi
2025-01-24 14:20 ` Knop, Ryszard
2025-01-29 18:14 ` Petri Latvala
2025-01-22 1:45 ` ✓ Xe.CI.BAT: success for Add igt_runner's cmdline to results (rev2) Patchwork
2025-01-22 1:49 ` ✓ i915.CI.BAT: " Patchwork
2025-01-22 10:11 ` ✗ Xe.CI.Full: failure " Patchwork
2025-01-23 10:42 ` ✗ i915.CI.Full: " 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=Z5puykM91cje2ki8@adrinael.net \
--to=adrinael@adrinael.net \
--cc=gustavo.sousa@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=kamil.konieczny@linux.intel.com \
--cc=lucas.demarchi@intel.com \
--cc=peter.senna@linux.intel.com \
--cc=ryszard.knop@intel.com \
/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.