Re: [Ksummit-discuss] Fwd: [TECH TOPIC] QR encoded oops for the kernel

[Levente Kurusa <levex@linux.com>]

[-- Attachment #1: Type: text/plain, Size: 2941 bytes --]

Hi,

On Wed, May 14, 2014 at 03:55:23PM -0700, Josh Triplett wrote:
> On Wed, May 14, 2014 at 10:00:43PM +0200, Levente Kurusa wrote:
> > On Wed, May 14, 2014 at 11:54:49AM -0700, Josh Triplett wrote:
> > > On Wed, May 14, 2014 at 09:00:51AM -0700, H. Peter Anvin wrote:
> > > > On 05/13/2014 12:08 AM, Josh Triplett wrote:
> > > > > 
> > > > > Many users will already have a QR-code scanning app installed, and such
> > > > > apps always support loading URLs in a browser.
> > > > > 
> > > > 
> > > > Let me disavow you of the notion that stock scanning apps handle large
> > > > QR symbols.
> > > 
> > > That's certainly true.  On the other hand, I'd really like to see a
> > > version of the oops-as-QR-code bits that uses VGA block characters to
> > > work in non-graphics, non-framebuffer mode, which would require fitting
> > > in at most 80x50 (using the half-block characters).  That wouldn't allow
> > > nearly as much data, but likely enough for a somewhat useful crash
> > > report, especially in aggregate.
> > 
> > Not really possible, from my experiences the QR code that results from
> > a random oops is ranging from 100x100 to 150x150 depending on the size
> > of stack trace and stuff like that. Of course, we can decrease the
> > error recovery region and that might make it smaller. I'll take a look
> > at this a bit later. If that doesn't work, then that means that we can't
> > shuffle that into the textmode's 80x25. Not to mention that the block
> > characters in the ASCII table (I think you meant that, if not please
> > correct me) are not neccessarily square, which is needed for maximum
> > scannability.
> 
> In the standard EGA/VGA/DOS character font, see characters DB (solid
> block), DC (lower half block), and DF (upper half block).  Those allow
> drawing 80x50 on an 80x25 console.  Unicode has those as well, and also
> supports a full set of quarter-character blocks which would allow
> 160x50; see U+2580 through U+259F.
> 

Hm, I see. I'll find some time soon to check on this.

> I've also seen discussions about removing less useful information from
> the oops backtrace (simplifying it to just the backtrace itself, and
> less of the guessed-at information).

Indeed, that might as well make the QR code smaller. I was thinking
about what really is the point in having the registers in the QR code
as well. I guess that is something we could leave out, right?

> 
> > One thing that we currently support and can be a solution is Micro QR
> > code. It removes two of the three coordinators and does some more
> > compression AFAIK. It might be possible to shuffle that into textmode.
> 
> How widely do stock barcode reader apps support that?

No idea, but, sadly, mine does not support MicroQR. (At least it was
not able to read the MicroQR example found on Wikipedia). I have
NeoReader as a stock scanner.

Thanks,
    Levente Kurusa

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]