[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <00ba01cd5565$c4848750$4d8d95f0$@cs.wisc.edu>
Date: Thu, 28 Jun 2012 14:39:38 -0500
From: "Matt Renzelmann" <mjr@...wisc.edu>
To: "'Dan Carpenter'" <dan.carpenter@...cle.com>,
"'Bryan Wu'" <bryan.wu@...onical.com>
Cc: "'Richard Purdie'" <rpurdie@...ys.net>,
<linux-leds@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<kernel-janitors@...r.kernel.org>,
"'Matt Renzelmann'" <mjr@...wisc.edu>
Subject: RE: [patch -resend] leds-lp5523: BUG() in error handling in probe()
> >
> > Just be curious, what's kind of the tool here?
> >
>
> Sorry I should have CC'd Matt on this. I think it's something he
> is working on at the University of Wisconsin. That's all I know.
>
> regards,
> dan carpenter
>
> > -Bryan
Dan is correct. We've submitted the project for publication but whether it will
be accepted is another question. If it's published I'd be happy to provide a
reference.
In a nutshell, the tool we've developed uses symbolic execution to reduce the
need for device hardware for driver testing and execute real Linux drivers in
the kernel. It provides symbolic data in place of hardware input. The tool
allows us to run real drivers even if the hardware is unavailable. It can't
find all bugs, but it can find many that could manifest in real conditions, e.g.
null pointer dereferences, incorrect kernel API usage, some "panics" and "BUG"
calls, etc.
I'll try to remember to write back when it's published, at which point I'd be
happy to provide more detail.
Thanks for the interest,
Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists