Messages in this thread | | | Date | Wed, 19 Mar 2014 22:18:35 +0200 | Subject | Re: [RFC] QR encoding for Oops messages | From | Teodora Băluţă <> |
| |
On Wed, Mar 19, 2014 at 8:03 PM, Borislav Petkov <bp@alien8.de> wrote: > On Mon, Mar 17, 2014 at 02:59:47PM -0700, Teodora Baluta wrote: >> This feature encodes Oops messages into a QR barcode that is scannable by >> any device with a camera. >> >> If the config option for this feature is enabled, then when an Oops is >> in progress, the printk() calls' strings are buffered. When the Oops >> finishes, the buffer is compressed, encoded into a QR and then displayed >> to frame buffer. The compression is done with zlib from lib/. >> >> Current issues: >> * the QR code is sometimes displayed on top of the console text, >> sometimes under it, thus making it unscannable >> * the compression rate could be better than what zlib offers >> * not tested for Oops messages issued from several CPUs >> >> As far as decoding is concerned, there are a lot of apps on mobile devices >> that decode QR codes (just text mostly). In order to make this work, an >> app which also decodes the QR code is needed. I will be working the next >> couple of weeks on an Android app which scans the Oops encoding QR and >> sends it to a server which keeps track of these Oopses that are sent to >> it making a sort of stream of the latest Oopses. Any thoughts on what the best >> workflow would be are more than welcomed. >> >> Also, if there are any suggestions on how to solve some of the issues, >> they are more than welcomed. > > Definitely a great idea. Which tree is the patch against? > > Thanks.
I started working from Linus's source tree that's up on github. To be more exact, version 3.14.0-rc2.
Thank you for taking interest in this!
-- Teodora
> > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > --
| |