All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel Sangorrin" <daniel.sangorrin@toshiba.co.jp>
To: "'Bird, Timothy'" <Tim.Bird@sony.com>, fuego@lists.linuxfoundation.org
Subject: Re: [Fuego] [PATCH 2/3] cyclictest: modify specs
Date: Tue, 7 Nov 2017 16:33:21 +0900	[thread overview]
Message-ID: <009301d3579a$b060a460$1121ed20$@toshiba.co.jp> (raw)
In-Reply-To: <ECADFF3FD767C149AD96A924E7EA6EAF40ACD26D@USCULXMSG01.am.sony.com>



> -----Original Message-----
> From: Bird, Timothy [mailto:Tim.Bird@sony.com]
> Sent: Thursday, November 02, 2017 2:16 AM
> To: Daniel Sangorrin; fuego@lists.linuxfoundation.org
> Subject: RE: [Fuego] [PATCH 2/3] cyclictest: modify specs
> 
> 
> 
> > -----Original Message-----
> > From: fuego-bounces@lists.linuxfoundation.org [mailto:fuego-
> > bounces@lists.linuxfoundation.org] On Behalf Of Daniel Sangorrin
> > Sent: Tuesday, October 31, 2017 1:32 AM
> > To: fuego@lists.linuxfoundation.org
> > Subject: [Fuego] [PATCH 2/3] cyclictest: modify specs
> >
> > cyclictest params can be very flexible so instead of
> > giving a fixed pattern we use a single variable PARAMS
> > to hold them.
> >
> > TODO: make builds parameterizable so that users can
> > modify the PARAMS from ftc without needing to create
> > a new spec.
> 
> Just a comment on this.  I support this idea, and it's actually
> pretty easy to do.  We just need to be careful that this doesn't negatively
> affect another of Fuego's goal, which is sharing of 1) methods of invoking
> test programs, and 2) ability to compare results from multiple systems.
> 
> Test specs are one of the primary ways that Fuego users can share their
> experience with each other - by creating canonical sets of build variables
> that produce meaningful results for particular test scenarios.
> 
> If use of custom parameters for tests becomes widespread, then it becomes
> less useful to compare results between different Fuego sites.
> 
> I'm not saying we shouldn't add the feature, just be judicious in it's
> use, and possibly provide recommendations for when it would be
> appropriate or not.

Yes, I was thinking that ftc could create the spec.json automatically 
on the log folder and then put the corresponding shell environment 
variable to it (actually this can be done in the general case as well). 
Once it's in the log folder, we can share it.

Another thing we could add is "default" parameters so that users
only need to modify those that are important to them and leave the
rest untouched. Maybe that's easy to do by just specifying the base
"default" parameters with -s as now, and then override the variables.

Thanks,
Daniel








  reply	other threads:[~2017-11-07  7:33 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-31  8:31 [Fuego] cyclictest patches Daniel Sangorrin
2017-10-31  8:31 ` [Fuego] [PATCH 1/3] cyclictest: update build function Daniel Sangorrin
2017-10-31 17:30   ` Bird, Timothy
2017-10-31 18:53     ` Bird, Timothy
2017-10-31 17:49   ` Bird, Timothy
2017-10-31  8:31 ` [Fuego] [PATCH 2/3] cyclictest: modify specs Daniel Sangorrin
2017-10-31 19:56   ` Bird, Timothy
2017-11-01  0:28     ` Daniel Sangorrin
2017-11-01 17:52       ` Bird, Timothy
2017-11-07  7:27         ` Daniel Sangorrin
2017-11-01 17:16   ` Bird, Timothy
2017-11-07  7:33     ` Daniel Sangorrin [this message]
2017-11-08  0:44       ` Bird, Timothy
2017-10-31  8:31 ` [Fuego] [PATCH 3/3] cyclictest: modify parsing and test measures Daniel Sangorrin
2017-11-01  0:43   ` Bird, Timothy
2017-11-01 17:11   ` Bird, Timothy
2017-10-31  8:39 ` [Fuego] cyclictest patches Daniel Sangorrin
2017-10-31 17:27   ` Bird, Timothy
2017-10-31 19:32     ` Bird, Timothy
2017-11-01  0:25     ` Daniel Sangorrin
2017-10-31 16:45 ` Bird, Timothy

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='009301d3579a$b060a460$1121ed20$@toshiba.co.jp' \
    --to=daniel.sangorrin@toshiba.co.jp \
    --cc=Tim.Bird@sony.com \
    --cc=fuego@lists.linuxfoundation.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.