All of lore.kernel.org
 help / color / mirror / Atom feed
From: Satoru Takeuchi <satoru.takeuchi@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Satoru Takeuchi <satoru.takeuchi@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] ktest: remove the misleading $buildonly and introduce $laststep.
Date: Tue, 11 Mar 2014 20:43:40 +0900	[thread overview]
Message-ID: <87ppltvu37.wl%satoru.takeuchi@gmail.com> (raw)
In-Reply-To: <20140310121300.485d2202@gandalf.local.home>

At Mon, 10 Mar 2014 12:13:00 -0400,
Steven Rostedt wrote:
> 
> On Sun, 09 Mar 2014 23:36:49 +0900
> Satoru Takeuchi <satoru.takeuchi@gmail.com> wrote:
> 
> > From: Satoru Takeuchi <satoru.takeuchi@gmail.com>
> > 
> > Each test of ktest consists of the following steps.
> > 
> >   build -> install -> boot -> run user defined tests.
> > 
> > $buildonly means not whether the test is build onlyor not. Actually
> > this variable mean the last step of the test as follows.
> > 
> >  0: boot or more
> >  1: build
> >  2: install
> > 
> > AS you can see, these are random numeric literals. In addition,
> > there is no explanation about them.
> > 
> > To improve readability, introduce $laststep instead of $buildonly.
> > This variable means the last step of the test as follows.
> > 
> >  STEP_BUILD (=0):        build
> >  STEP_INSTALL (=1):      install
> >  STEP_BOOT_OR_MORE (=2): boot or more
> 
> Nice clean up. But there's some bugs in this patch.
> 
>  
> > @@ -649,26 +651,20 @@ sub set_value {
> >  
> >      my $prvalue = process_variables($rvalue);
> >  
> > -    if ($buildonly && $lvalue =~ /^TEST_TYPE(\[.*\])?$/ && $prvalue ne "build") {
> > -	# Note if a test is something other than build, then we
> > -	# will need other manditory options.
> > -	if ($prvalue ne "install") {
> > -	    # for bisect, we need to check BISECT_TYPE
> > -	    if ($prvalue ne "bisect") {
> > -		$buildonly = 0;
> 
> When prvalue ne "bisect" we set it to boot or more.
> 
> > +    if ($laststep <= STEP_INSTALL)  {
> > +	if ($lvalue =~ /^TEST_TYPE(\[.*\])?$/ && $prvalue ne "build") {
> > +	    # Note if a test is something other than build, then we
> > +	    # will need other manditory options.
> > +	    if ($prvalue eq "install") {
> > +		# install still limits some manditory options.
> > +		$laststep = STEP_INSTALL;
> > +	    } elsif ($prvalue ne "bisect") {
> > +		# for bisect, we need to check BISECT_TYPE
> > +		$laststep = STEP_BUILD;
> 
> Here you set it back to build.
> 
> >  	    }
> > -	} else {
> > -	    # install still limits some manditory options.
> > -	    $buildonly = 2;
> > -	}
> > -    }
> > -
> > -    if ($buildonly && $lvalue =~ /^BISECT_TYPE(\[.*\])?$/ && $prvalue ne "build") {
> > -	if ($prvalue ne "install") {
> > -	    $buildonly = 0;
> > -	} else {
> > -	    # install still limits some manditory options.
> > -	    $buildonly = 2;
> > +	} elsif ($lvalue =~ /^BISECT_TYPE(\[.*\])?$/ &&
> > +		   $prvalue ne "build") {
> > +	    $laststep = ($prvalue eq "install") ? STEP_INSTALL : STEP_BUILD;
> 
> Here too.
> 
> In fact, with this patch, we never set to boot or more.

Sorry, my code review and test are insufficient.

> 
> Also, you can make it even cleaner, by having the outer if condition be:
> 
> 	if ($laststep <= STEP_INSTALL && $prvalue ne "build")
> 
> And remove the prvalue check from the inner conditions.

Thank you fo your comment.

> 
> Just send a fix of this patch, I have already pulled in the other two.

Thanks, I'll do.

> I just need to test them for a bit before I push them to my kernel.org
> repo. I don't actually have a test suite for ktest. My testing is that
> I use ktest on a daily basis, and I just use the latest devel ktest for
> my daily activities. If something breaks, I usually notice, unless it's
> affects something I haven't done recently (like a bisect).

I'll make and send my testsuite later. I considers that
tools/testing/ktest/example is suitable to place it.

Thanks,
Satoru

> 
> Thanks,
> 
> -- Steve
> 
> >  	}
> >      }
> >  
> > @@ -4045,7 +4041,7 @@ for (my $i = 1; $i <= $opt{"NUM_TESTS"}; $i++) {
> >      $dmesg = "$tmpdir/dmesg-$machine";
> >      $output_config = "$outputdir/.config";
> >  
> > -    if (!$buildonly) {
> > +    if ($laststep >= STEP_BOOT_OR_MORE) {
> >  	$target = "$ssh_user\@$machine";
> >  	if ($reboot_type eq "grub") {
> >  	    dodie "GRUB_MENU not defined" if (!defined($grub_menu));
> 

  reply	other threads:[~2014-03-11 11:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-09 14:29 [PATCH 1/3] ktest: add 2nd parameter of run_command() to set the redirect target file Satoru Takeuchi
2014-03-09 14:32 ` [PATCH 2/3] ktest: Some cleanup for improving readability Satoru Takeuchi
2014-03-09 14:36   ` [PATCH 3/3] ktest: remove the misleading $buildonly and introduce $laststep Satoru Takeuchi
2014-03-10 16:13     ` Steven Rostedt
2014-03-11 11:43       ` Satoru Takeuchi [this message]
2014-03-11 11:50         ` Satoru Takeuchi
2014-03-11 19:56           ` Steven Rostedt

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=87ppltvu37.wl%satoru.takeuchi@gmail.com \
    --to=satoru.takeuchi@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.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.