mail for qr

re-qr-encoded-oops-for-the-kernel-060514.mbox

From: Levente Kurusa <levex@linux.com>
To: Teodora Băluţă <teobaluta@gmail.com>,
        Waskiewicz Jr, Peter P <pjwaskiewicz@gmail.com>,
        Jason Cooper <jason@lakedaemon.net>,
        Sarah Sharp <sarah@minilop.net>,
        Anton Arapov <arapov@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        "Theodore Ts'o" <tytso@mit.edu>
Cc: LKML <linux-kernel@vger.kernel.org>,
        Levente Kurusa <levex@linux.com>,
        H. Peter Anvin <hpa@zytor.com>,
        David Woodhouse <dwmw2@infradead.org>,
        Dirk Hohndel <hohndel@infradead.org>
Bcc: 
In-Reply-To: <CAAsK9AHesqBOwYEaovg5m-Rxcd+_xnk-eN+EURxECYUBAsTC7A@mail.gmail.com>
Subject: Re: [RFC] QR encoding for Oops messages

Hi all,

So since the ksummit-discuss list was not intended for technical
discussions, let us move the discussion here to the LKML.

Let me start with the current state of the project.

* We have a basic prototype, which can render the QR code to
  the screen via the basic framebuffer API. (i.e. we use the
  registered_fb array to get a handle of the FB)

* Since we use the framebuffer API, we can't really render
  at the moment in textmode and its variants. This is something
  that most people had requested and so far the most feasible way
  is to reprogram the VGA driver to a 640x480 display.

* We had implemented a core_param called qr_oops which if zero,
  disables the QR encoding at all. A bonus feature is that if you
  give it a number greater than one, then the resulting QR code will
  be scaled. Obviously, we have safe guards against too big scalings.

* I have added a check against recursive oopses in the QR encoding
  library. That is, if the library crashes we won't go into an
  infinite loop of oopses.

* The raw oops is compressed with zlib in the kernel and then encoded
  as 8bit data into the QR code. This might change depending on which
  way we decide to take.

Here are a few problems with the current state:

* The QR code is considerably big. It is roughly 120x120 on scale 1,
  if scaled (which is probably preferred, since otherwise people will
  not be able to simply scan it) then it usually takes around 80%-90%
  of the screen, which *might* make some people angry if their distro
  decides to compile in this feature and set a scale...

* If there is a new OOPS immediately after the last one, then the
  first QR code will get overwritten. (They will not 'mix' since we
  clear the designated area for the QR code to full white before we
  write the QR blocks)

* If there is a kernel panic right after the oops, then the QR code
  will get mangled into a mess of characters and white/black pixels.
  In a few cases this is still scannable due to the error recovery
  in the QR code, but I really don't think we should rely on that.

Ideas that need discussion:

* Only record the first oops. I don't see how could we still have
  the QR code output if in the meantime we get a new oops, which
  will most likely overwrite the screen. (Steven Rostedt)

* File a bug in bugzilla once the bug has been reported.
  (Sarah Sharp)

* How to encode (and compress!) the oops so that we can get
  the most people up for it? zlib+base64 in a URL so any reader
  might be able to read it or zlib and then a custom app is required?
  (various people)

In case somebody does not know, the project can be found here:

http://github.com/teobaluta/qr-linux-kernel

Suggestions, blames and everything in general is welcome.

Thanks,
    Levente Kurusa