Pull ktest updates from Steven Rostedt:
"These commits have either been sitting in my INBOX or have been in my
local tree for some time. I need to push them upstream:
- Separate out config-bisect.pl from ktest.pl.
This allows users to do config bisects without full ktest setup.
- Email on status change.
Allow the user to be emailed on test start, finish, failure, etc.
- Other small fixes and enhancements"
* tag 'ktest-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-ktest: (24 commits)
ktest: Take submenu into account for grub2 menus
ktest.pl: Add MAIL_COMMAND option to define how to send email
ktest.pl: Use run_command to execute sending mail
ktest.pl: Allow dodie be recursive
ktest.pl: Kill test if mailer is not supported
ktest.pl: Add MAIL_PATH option to define where to find the mailer
ktest.pl: No need to print no mailer is specified when mailto is not
Ktest: add email options to sample.config
Ktest: Use dodie for critical falures
Ktest: Add SigInt handling
Ktest: Add email support
ktest.pl: Detect if a config-bisect was interrupted
ktest.pl: Make finding config-bisect.pl dynamic
ktest.pl: Have ktest.pl pass -r to config-bisect.pl to reset bisect
ktest.pl: Use diffconfig if available for failed config bisects
ktest.pl: Allow for the config-bisect.pl output to display to console
ktest: Use config-bisect.pl in ktest.pl
ktest: Add standalone config-bisect.pl program
ktest: Set do_not_reboot=y for CONFIG_BISECT_TYPE=build
ktest: Set buildonly=1 for CONFIG_BISECT_TYPE=build
...
Allow the user to override the default way to send email. This will allow
the user to add their own mailer and format for sending email.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Instead of open coding system() call, use run_command which will log the
sending of email as well.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
If dodie cause a function that itself will call dodie, then be able to
handle that. This will allow dodie functions to call run_command, which
could possibly call dodie. If dodie is called again, simply ignore it.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
The option MAIL_PATH lets the user decide how to find the mailer they are
using. For example, sendmail is usually located in /usr/sbin but is not
always in the path of non admin users. Have ktest look through the user's
PATH environment variable (adding /usr/sbin) as well, but if that's not good
enough, allow the user to define where to find the mailer.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
squash to mail exec
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
If the user doesn't want to send mail, then don't bother them with output
that says they didn't specify a mailer. That can be annoying.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Users should get emails when the script dies because of a critical failure.
Critical failures are defined as any errors that could abnormally terminate
the script.
In order to add email support, this patch converts all die() to dodie() except:
* when '-v' is used as an option to get the version of the script.
* in Sig-Int handeler because it's not a fatal error to cancel the script.
* errors happen during parsing config
Link: http://lkml.kernel.org/r/1522094884-22718-4-git-send-email-tianyang.chen@oracle.com
Suggested-by: Dhaval Giani <dhaval.giani@oracle.com>
Signed-off-by: Tim Tianyang Chen <tianyang.chen@oracle.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Users can define optional variables to get email notifications.
Ktest can send emails when the script:
* was started
* failed with fatal errors and called dodie()
* completed all testing
Users have to setup the mailer provided in config prior to using this script.
Supported mailers: mailx, mail, sendmail
mailer specific routines are _sendmail_send(), _mailx_send()
Link: http://lkml.kernel.org/r/1522094884-22718-2-git-send-email-tianyang.chen@oracle.com
Suggested-by: Dhaval Giani <dhaval.giani@oracle.com>
Signed-off-by: Tim Tianyang Chen <tianyang.chen@oracle.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
If a config-bisect was interrupted, then allow the user to continue, or
restart a new config-bisect.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Just looking for config-bisect.pl in the source tree can be risky,
especially, if the source tree being tested doesn't have config-bisect.pl in
place. Instead, allow the user to set where to find config-bisect.pl with a
new option CONFIG_BISECT_EXEC.
If this option is not set, by default, ktest.pl will look for
config-bisect.pl in the following locations:
`pwd`/config-bisect.pl # where ktest.pl was called from
`dirname /path/to/ktest.pl`/config-bisect.pl # where ktest.pl exists
${BUILD_DIR}/tools/testing/ktest/config-bisect.pl
# where config-bisect.pl exists in the source tree.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
If config-bisect.pl sees that a config_bisect has already been started, it
will ask on the command line if it should bisect or not. This will mess up
running config_bisect from ktest.pl.
Have ktest.pl pass in '-r' to config-bisect.pl and have config-bisect.pl
recognize that to reset without asking.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Check to see if diffconfig is available and use that to diff the configs
instead of using 'diff -u', as diffconfig produces much better output of
kernel config files. It checks the source directory for the executable.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
When commands are run in ktest, they are only displayed in the ktest log
file, but that is not sufficient for outputting the display for config
bisects. The result of a config bisect is not shown.
Add a way to display the output of "run_command" which is the subroutine
used by ktest to execute commands. Use this feature to display the output of
config-bisect.pl executions to see the progress as well as the result.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Reduce code duplication and take advantage of bisection logic
improvements by calling config-bisect.pl.
The output of make oldconfig is now copied directly to the desired file,
rather than doing assign_configs+save_config, in order to preserve the
ordering so that diffing the configs at the end will provide useful
output.
Link: http://lkml.kernel.org/r/20170717001630.10518-8-swood@redhat.com
Signed-off-by: Scott Wood <swood@redhat.com>
[ Modified to use with new version of config-bisect.pl ]
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Started working on a stand alone program that can do a config bisect. It is
based on the config bisect code of ktest.pl. Instead of needing all the
infrastructure of ktest.pl, all that is required for config-bisect.pl is two
config files. One that works, and one that does not. The goal is to pass in
the two files, and it will create a new "good" and a new "bad" config file
based on input from the user. After several iterations (calls to this
program), it will eventually end with a minimum config value that allows one
config to work and the other config to break.
The program uses a technique that takes the good config and then makes half
of the configs that differ from the bad config just like the bad config.
The code will use make oldconfig to make sure the configs that are set are
not all converted back due to incorrect dependencies on other configs set in
the bad config but not in the new test config.
This is still a work in progress, but as it was written while I was working
at Red Hat, I want this code to be submitted as such.
Signed-off-by: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
A number of architectures are being removed from the kernel, so
we no longer need to test them.
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
ktest.pl will read any file as long as its name is specified as the first
argument on the command line. Comment this fact in sample.conf.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Before ktest issues a reboot, it will try to connect to the target machine
to make sure that it is still alive. If the target does not respond within 5
seconds, it will power cycle the box instead of issuing a reboot.
Five seconds may be too short, and ktest may unnecessarially power cycle the
box. I have found 25 seconds seems to be a better timeout for this purpose.
But even 25 may be too arbitrary. Add a CONNECT_TIMEOUT option to let the
user determine the timeout time before rebooting. By default, it has been
raised to 25 seconds.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
