[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120925194019.GA25626@kroah.com>
Date: Tue, 25 Sep 2012 12:40:19 -0700
From: Greg KH <gregkh@...uxfoundation.org>
To: Steven Rostedt <srostedt@...hat.com>
Cc: linux-kernel@...r.kernel.org, rostedt@...dmis.org
Subject: Re: ktest.pl always returns 0?
On Tue, Sep 25, 2012 at 02:15:17PM -0400, Steven Rostedt wrote:
> On Tue, 2012-09-25 at 11:00 -0700, Greg KH wrote:
> > Hi Steven,
>
> Note, emailing my RH account is hit or miss. If I'm traveling I don't
> read it, and I wont return messages until I'm back. It's best to email
> my rostedt@...dmis.org account, as I have better access to that account.
> I author my patches by the email of the people that pay me to write
> them. This isn't for your "who wrote the kernel" scripts. This is for
> anyone that happens to do a git log.
Hey, it's not my fault your employer has a crummy email system that
can't handle remote access well, I just went off of the Author: line in
your ktest.pl kernel commits :)
> > I'm trying to use ktest to do build tests of the stable patch series to
> > verify I didn't mess anything up, but I'm finding that ktest always
> > returns 0 when finished, no matter if the build test was successful or
> > failed.
>
> Hmm, I should fix that. Yeah, I agree, if it fails a test it should
> return something other than zero. But I think that only happens if you
> have DIE_ON_FAILURE = 0. As IIRC, the perl "die" command should exit the
> application with an error code.
>
> But yeah, I agree, if one of the tests fail, the error code should not
> be zero. I'll write up a patch to fix that. Or at least add an option to
> make that happen.
That would be great.
> > Is this right? Is there some other way to determine if ktest fails
> > other than greping the output log?
>
> If you have DIE_ON_FAILURE = 1 (default) it should exit with non zero.
It doesn't do that, test it and see (this is with what is in Linus's
3.6-rc7 tree, I didn't test linux-next if that is newer, my apologies.)
> > Oh, and any hints on kicking off a ktest process on a remote machine in
> > a "simple" way? I'm just using ssh to copy over a script that runs
> > there, wrapping ktest.pl up with other stuff, I didn't miss the fact
> > that ktest itself can run remotely already, did I?
>
> I'm a little confused by this question. Do you want a server ktest? That
> is, have a ktest daemon that listens for clients that sends it config
> files and then runs them? That would actually be a fun project ;-)
>
> You're not running ktest on the target machine are you? The way I use it
> is the following:
>
> I have a server that I ssh to and run ktest from. It does all the builds
> there on the server and this server has a means to monitor some target.
> I use ttywatch that connects to the serial of the target, in which ktest
> uses to read from.
>
> Sometimes this "server" is the machine I'm logged in to. And I just run
> ktest directly.
>
> Can you explain more of what you are looking for?
I want to be able to say:
- take this set of stable patches and go run a 'make
allmodconfig' build on a remote machine and email me back the
answer because I might not be able to keep an internet
connection open for the next 5-15 minutes it might take to
complete that task.
I don't do boot tests with these kernel build tests, although sometime
in the future it would be nice to do that. Right now I do that testing
manually, as it's pretty infrequent (once per release usually.)
So yes, a 'ktest' server would be nice. I've attached the (horrible)
script below that I'm using for this so far. It seems to work well, and
I can do builds on a "cloud" server as well as my local build server
just fine, only thing needed to do is change the user and machine name
in the script.
I know ktest doesn't handle quilt patches yet, which is why I apply them
"by hand" now to a given git tree branch, if you ever do add that
option, I'll gladly test it out and change my script to use whatever
format it needs.
thanks,
greg k-h
View attachment "ts" of type "text/plain" (4648 bytes)
Powered by blists - more mailing lists