[Ksummit-2012-discuss] [ATTEND] kernel core dump and "dying breath"
will.deacon at arm.com
Mon Jun 25 09:43:30 UTC 2012
On Fri, Jun 22, 2012 at 09:46:10PM +0100, Arnd Bergmann wrote:
> On Friday 22 June 2012, Matthew Garrett wrote:
> > On Thu, Jun 21, 2012 at 04:59:52PM -0700, H. Peter Anvin wrote:
> > > It is something I and Dirk Hohndel have been messing with from time to
> > > time. Unfortunately it appears that most QR encoders and/or decoders
> > > don't handle large data symbols very well, and a lot of them only handle
> > > plain ASCII modes. This isn't inherently a showstopper -- we really
> > > only need one known reliable encoder and decoder. Doing an encoder
> > > isn't very hard, but doing a decoder that can accept photographs taken
> > > under non-ideal conditions is harder.
> > The decoder problem is already solved. Just embed it as a link and
> > provide a web service for decoding the backtrace and then people can use
> > their existing smartphone QR software.
> I believe it was Will Deacon and Marc Zyngier who did a prototype of this
> during Linaro Connect in Hong Kong.
Well, I think `prototype' is a bit strong but we did take a look at the
feasibility of using QR codes for backtraces. The two problems were:
1. Even without any error correction, the QR code started to get pretty
large (and unreadable) after more than a few lines of backtrace. This
should be fairly easy to fix by encoding the data in a more sensible
manner rather than just verbatim (especially since a backtrace is
a well-structured log). Maybe you could even gzip the whole thing after
that too (then sell an android app to gunzip it :p)
2. Displaying the QR code on a panic could be problematic. We tried using
the ASCII option of libqrencode but we couldn't find any phone that
would read the result. So we need a way to get to the framebuffer once
we've sawn our head off (maybe this is easier with x86 and VGA modes?).
More information about the Ksummit-2012-discuss