Re: [RFC] QR encoding for Oops messages
From: Jason Cooper
Date: Fri Mar 21 2014 - 09:28:48 EST
On Wed, Mar 19, 2014 at 10:38:30PM +0200, Teodora BÄluÅÄ wrote:
> On Wed, Mar 19, 2014 at 10:18 PM, Dave Jones <davej@xxxxxxxxxx> 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.
> >
> > ...
> >
> > > include/linux/print_oops.h | 11 +
> > > include/linux/qrencode.h | 546 +++++++++++++
> > > kernel/Makefile | 1 +
> > > kernel/panic.c | 5 +
> > > kernel/print_oops.c | 173 +++++
> > > kernel/printk/printk.c | 9 +-
> > > lib/Kconfig | 5 +
> > > lib/Kconfig.debug | 11 +
> > > lib/Makefile | 3 +
> > > lib/qr/Makefile | 6 +
> > > lib/qr/bitstream.c | 233 ++++++
> > > lib/qr/bitstream.h | 37 +
> > > lib/qr/mask.c | 320 ++++++++
> > > lib/qr/mask.h | 39 +
> > > lib/qr/mmask.c | 175 +++++
> > > lib/qr/mmask.h | 36 +
> > > lib/qr/mqrspec.c | 259 +++++++
> > > lib/qr/mqrspec.h | 155 ++++
> > > lib/qr/qrencode.c | 871 +++++++++++++++++++++
> > > lib/qr/qrencode.h | 546 +++++++++++++
> > > lib/qr/qrinput.c | 1834 ++++++++++++++++++++++++++++++++++++++++++++
> > > lib/qr/qrinput.h | 129 ++++
> > > lib/qr/qrspec.c | 543 +++++++++++++
> > > lib/qr/qrspec.h | 178 +++++
> > > lib/qr/rscode.c | 325 ++++++++
> > > lib/qr/rscode.h | 38 +
> > > lib/qr/split.c | 331 ++++++++
> > > lib/qr/split.h | 44 ++
> > > 28 files changed, 6860 insertions(+), 3 deletions(-)
> >
> > That's a ton of code we're adding into one of the most fragile parts of the kernel.
> >
> > A lot of what libqrencode does would seem to be superfluous to the requirements
> > here, as we don't output kernel oopses in kanji for eg, and won't care about
> > multiple versions of the qr spec.
>
> That's true. I didn't do that much cleanup in the library afraid of
> breaking something and focused that I get this done one way or
> another. Indeed, the library is userspace and is made to be versatile
> rather than small.
Perhaps you could add libqr to the staging tree? As long as it
compiles, it can go there. Then you can focus on cleanups and bloat
removal. In the process, you'll get a larger testing base because it
will be in mainline.
You may be interested in objdiff [1] which I'm using for merging code
into the staging tree [2]. It provides an automated way to determine
that code cleanups didn't change the resultant object code. You can see
an example run here [3].
I would definitely like to see the QR output incorporated into a
kernel.org url. That would remove the need for installing another app,
and would ease bug reporting.
Anyway, if you're interested, I'll be re-posting a patch for objdiff
separately maybe today or this weekend.
thx,
Jason.
[1] https://lkml.kernel.org/r/cc773270b6481ffe69516d994fbe98c13bcfdb5a.1394570067.git.jason@xxxxxxxxxxxxxx
[2] https://lkml.kernel.org/r/cover.1394570067.git.jason@xxxxxxxxxxxxxx
[3] https://lkml.kernel.org/r/20140312165501.GC7811@xxxxxxxxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/