Re: [RFC] QR encoding for Oops messages
Hi, 2014-04-08 19:29 GMT+02:00 Levente Kurusa : > Hi, > > On 04/08/2014 07:20 PM, Jason Cooper wrote: >> On Tue, Apr 08, 2014 at 05:42:00PM +0200, Levente Kurusa wrote: >>> On 04/07/2014 05:20 PM, Jason Cooper wrote: On Sat, Apr 05, 2014 at 11:11:02AM +0200, Levente Kurusa wrote: > Oh and another suggestion, I think placing it in the bottom-right > corner would be better since then we wouldn't overwrite some of > the timestamps and messages. The real text is still sent to the (hopefully written to disk) logs. If a user (or distro) builds with this feature, I would think centered and scaled for ease of scanning would be highest priority. >>> >>> Yup, I'll be traveling on the train a lot this week, so I'll >>> have plenty of time to implement scaling and centering. Maybe >>> we could also implement this: >>> >>> qr_oops=center (center the QR code with scale 1) >>> qr_oops=center,3 (center the QR code with scale 3) >>> >>> 'center' could also be 'topleft', 'bottomright', etc. >>> Or just remain at the KISS rule? (keep it simple) >>> >>> Any objections? >> >> KISS. ;-) >> >> Iff we find we need the feature later, we can always add qr_oops_pos or >> similar. >> > > Alright, I'll start the work on that tomorrow. > > Maybe I'll also find some time to clean up the library, > since I guess that should be our primary priority. Just a quick reminder that scaling was just merged in [0]. I'd highly appreciate feedback. Thanks! Now that rendering is a bit cleaner I'll start cleaning up the library. This is what I intend to do next week: * Extract bitstream.c into a new kernel library. No point in restricting this to QR only. * Rework bitstream to propagate errors, to use a caller allocation scheme and remove the ugly OOPness. * Fix up the QR library so that it propagates errors from the new bitstream code. Any objections? [0]: https://github.com/teobaluta/qr-linux-kernel/commit/70401a9918e0810e7b0784fa6e1bdc766df20352 -- Regards, Levente Kurusa PGP: 4EF5D641 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
Hi, 2014-04-08 19:29 GMT+02:00 Levente Kurusa le...@linux.com: Hi, On 04/08/2014 07:20 PM, Jason Cooper wrote: On Tue, Apr 08, 2014 at 05:42:00PM +0200, Levente Kurusa wrote: On 04/07/2014 05:20 PM, Jason Cooper wrote: On Sat, Apr 05, 2014 at 11:11:02AM +0200, Levente Kurusa wrote: Oh and another suggestion, I think placing it in the bottom-right corner would be better since then we wouldn't overwrite some of the timestamps and messages. The real text is still sent to the (hopefully written to disk) logs. If a user (or distro) builds with this feature, I would think centered and scaled for ease of scanning would be highest priority. Yup, I'll be traveling on the train a lot this week, so I'll have plenty of time to implement scaling and centering. Maybe we could also implement this: qr_oops=center (center the QR code with scale 1) qr_oops=center,3 (center the QR code with scale 3) 'center' could also be 'topleft', 'bottomright', etc. Or just remain at the KISS rule? (keep it simple) Any objections? KISS. ;-) Iff we find we need the feature later, we can always add qr_oops_pos or similar. Alright, I'll start the work on that tomorrow. Maybe I'll also find some time to clean up the library, since I guess that should be our primary priority. Just a quick reminder that scaling was just merged in [0]. I'd highly appreciate feedback. Thanks! Now that rendering is a bit cleaner I'll start cleaning up the library. This is what I intend to do next week: * Extract bitstream.c into a new kernel library. No point in restricting this to QR only. * Rework bitstream to propagate errors, to use a caller allocation scheme and remove the ugly OOPness. * Fix up the QR library so that it propagates errors from the new bitstream code. Any objections? [0]: https://github.com/teobaluta/qr-linux-kernel/commit/70401a9918e0810e7b0784fa6e1bdc766df20352 -- Regards, Levente Kurusa PGP: 4EF5D641 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
Hi, On 04/08/2014 07:20 PM, Jason Cooper wrote: > On Tue, Apr 08, 2014 at 05:42:00PM +0200, Levente Kurusa wrote: >> On 04/07/2014 05:20 PM, Jason Cooper wrote: >>> On Sat, Apr 05, 2014 at 11:11:02AM +0200, Levente Kurusa wrote: Oh and another suggestion, I think placing it in the bottom-right corner would be better since then we wouldn't overwrite some of the timestamps and messages. >>> >>> The real text is still sent to the (hopefully written to disk) logs. If >>> a user (or distro) builds with this feature, I would think centered and >>> scaled for ease of scanning would be highest priority. >> >> Yup, I'll be traveling on the train a lot this week, so I'll >> have plenty of time to implement scaling and centering. Maybe >> we could also implement this: >> >> qr_oops=center (center the QR code with scale 1) >> qr_oops=center,3 (center the QR code with scale 3) >> >> 'center' could also be 'topleft', 'bottomright', etc. >> Or just remain at the KISS rule? (keep it simple) >> >> Any objections? > > KISS. ;-) > > Iff we find we need the feature later, we can always add qr_oops_pos or > similar. > Alright, I'll start the work on that tomorrow. Maybe I'll also find some time to clean up the library, since I guess that should be our primary priority. -- Regards, Levente Kurusa PGP: 4EF5D641 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Tue, Apr 08, 2014 at 05:42:00PM +0200, Levente Kurusa wrote: > On 04/07/2014 05:20 PM, Jason Cooper wrote: > > On Sat, Apr 05, 2014 at 11:11:02AM +0200, Levente Kurusa wrote: > >> Oh and another suggestion, I think placing it in the bottom-right > >> corner would be better since then we wouldn't overwrite some of > >> the timestamps and messages. > > > > The real text is still sent to the (hopefully written to disk) logs. If > > a user (or distro) builds with this feature, I would think centered and > > scaled for ease of scanning would be highest priority. > > Yup, I'll be traveling on the train a lot this week, so I'll > have plenty of time to implement scaling and centering. Maybe > we could also implement this: > > qr_oops=center (center the QR code with scale 1) > qr_oops=center,3 (center the QR code with scale 3) > > 'center' could also be 'topleft', 'bottomright', etc. > Or just remain at the KISS rule? (keep it simple) > > Any objections? KISS. ;-) Iff we find we need the feature later, we can always add qr_oops_pos or similar. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
Hi, On 04/07/2014 05:20 PM, Jason Cooper wrote: > On Sat, Apr 05, 2014 at 11:11:02AM +0200, Levente Kurusa wrote: >> Or, we could use core_param and simply have 'oops_qr' or >> 'qr_oops'. In my humble opinion the latter sounds better. > > Ack. My original suggestion was focused on 0=disable, >0 is scale. I > literally pulled the name from my nether-regions. :-) Pushed to Teodora. Hopefully she will pull it soon. > >> Oh and another suggestion, I think placing it in the bottom-right >> corner would be better since then we wouldn't overwrite some of >> the timestamps and messages. > > The real text is still sent to the (hopefully written to disk) logs. If > a user (or distro) builds with this feature, I would think centered and > scaled for ease of scanning would be highest priority. Yup, I'll be traveling on the train a lot this week, so I'll have plenty of time to implement scaling and centering. Maybe we could also implement this: qr_oops=center (center the QR code with scale 1) qr_oops=center,3 (center the QR code with scale 3) 'center' could also be 'topleft', 'bottomright', etc. Or just remain at the KISS rule? (keep it simple) Any objections? > > I don't think there is a 'safe' part of the framebuffer real estate > where the QR could be written for all scenarios. Best to make it easy > to scan. Yea we also need to prevent it from happening on panics. Currently on panics, (i.e. exit when init=/bin/sh) will cause half of the QR code not rendered on screen due to some reason. It looks like it is due to scrolling, but I am not sure then why doesn't happen when I do 'echo c > /proc/sysrq-trigger' which as well causes a panic. Any ideas why this happens? -- Regards, Levente Kurusa PGP: 4EF5D641 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
Hi, On 04/07/2014 05:20 PM, Jason Cooper wrote: On Sat, Apr 05, 2014 at 11:11:02AM +0200, Levente Kurusa wrote: Or, we could use core_param and simply have 'oops_qr' or 'qr_oops'. In my humble opinion the latter sounds better. Ack. My original suggestion was focused on 0=disable, 0 is scale. I literally pulled the name from my nether-regions. :-) Pushed to Teodora. Hopefully she will pull it soon. Oh and another suggestion, I think placing it in the bottom-right corner would be better since then we wouldn't overwrite some of the timestamps and messages. The real text is still sent to the (hopefully written to disk) logs. If a user (or distro) builds with this feature, I would think centered and scaled for ease of scanning would be highest priority. Yup, I'll be traveling on the train a lot this week, so I'll have plenty of time to implement scaling and centering. Maybe we could also implement this: qr_oops=center (center the QR code with scale 1) qr_oops=center,3 (center the QR code with scale 3) 'center' could also be 'topleft', 'bottomright', etc. Or just remain at the KISS rule? (keep it simple) Any objections? I don't think there is a 'safe' part of the framebuffer real estate where the QR could be written for all scenarios. Best to make it easy to scan. Yea we also need to prevent it from happening on panics. Currently on panics, (i.e. exit when init=/bin/sh) will cause half of the QR code not rendered on screen due to some reason. It looks like it is due to scrolling, but I am not sure then why doesn't happen when I do 'echo c /proc/sysrq-trigger' which as well causes a panic. Any ideas why this happens? -- Regards, Levente Kurusa PGP: 4EF5D641 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Tue, Apr 08, 2014 at 05:42:00PM +0200, Levente Kurusa wrote: On 04/07/2014 05:20 PM, Jason Cooper wrote: On Sat, Apr 05, 2014 at 11:11:02AM +0200, Levente Kurusa wrote: Oh and another suggestion, I think placing it in the bottom-right corner would be better since then we wouldn't overwrite some of the timestamps and messages. The real text is still sent to the (hopefully written to disk) logs. If a user (or distro) builds with this feature, I would think centered and scaled for ease of scanning would be highest priority. Yup, I'll be traveling on the train a lot this week, so I'll have plenty of time to implement scaling and centering. Maybe we could also implement this: qr_oops=center (center the QR code with scale 1) qr_oops=center,3 (center the QR code with scale 3) 'center' could also be 'topleft', 'bottomright', etc. Or just remain at the KISS rule? (keep it simple) Any objections? KISS. ;-) Iff we find we need the feature later, we can always add qr_oops_pos or similar. thx, Jason. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
Hi, On 04/08/2014 07:20 PM, Jason Cooper wrote: On Tue, Apr 08, 2014 at 05:42:00PM +0200, Levente Kurusa wrote: On 04/07/2014 05:20 PM, Jason Cooper wrote: On Sat, Apr 05, 2014 at 11:11:02AM +0200, Levente Kurusa wrote: Oh and another suggestion, I think placing it in the bottom-right corner would be better since then we wouldn't overwrite some of the timestamps and messages. The real text is still sent to the (hopefully written to disk) logs. If a user (or distro) builds with this feature, I would think centered and scaled for ease of scanning would be highest priority. Yup, I'll be traveling on the train a lot this week, so I'll have plenty of time to implement scaling and centering. Maybe we could also implement this: qr_oops=center (center the QR code with scale 1) qr_oops=center,3 (center the QR code with scale 3) 'center' could also be 'topleft', 'bottomright', etc. Or just remain at the KISS rule? (keep it simple) Any objections? KISS. ;-) Iff we find we need the feature later, we can always add qr_oops_pos or similar. Alright, I'll start the work on that tomorrow. Maybe I'll also find some time to clean up the library, since I guess that should be our primary priority. -- Regards, Levente Kurusa PGP: 4EF5D641 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Sat, Apr 05, 2014 at 11:11:02AM +0200, Levente Kurusa wrote: > Or, we could use core_param and simply have 'oops_qr' or > 'qr_oops'. In my humble opinion the latter sounds better. Ack. My original suggestion was focused on 0=disable, >0 is scale. I literally pulled the name from my nether-regions. :-) > Oh and another suggestion, I think placing it in the bottom-right > corner would be better since then we wouldn't overwrite some of > the timestamps and messages. The real text is still sent to the (hopefully written to disk) logs. If a user (or distro) builds with this feature, I would think centered and scaled for ease of scanning would be highest priority. I don't think there is a 'safe' part of the framebuffer real estate where the QR could be written for all scenarios. Best to make it easy to scan. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Sat, Apr 05, 2014 at 11:11:02AM +0200, Levente Kurusa wrote: Or, we could use core_param and simply have 'oops_qr' or 'qr_oops'. In my humble opinion the latter sounds better. Ack. My original suggestion was focused on 0=disable, 0 is scale. I literally pulled the name from my nether-regions. :-) Oh and another suggestion, I think placing it in the bottom-right corner would be better since then we wouldn't overwrite some of the timestamps and messages. The real text is still sent to the (hopefully written to disk) logs. If a user (or distro) builds with this feature, I would think centered and scaled for ease of scanning would be highest priority. I don't think there is a 'safe' part of the framebuffer real estate where the QR could be written for all scenarios. Best to make it easy to scan. thx, Jason. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
Hi, On 04/04/2014 11:42 PM, Teodora Băluţă wrote: > On Fri, Apr 4, 2014 at 7:17 PM, Levente Kurusa wrote: >> Hi, >> >> On 04/04/2014 05:15 PM, Jason Cooper wrote: >>> On Thu, Apr 03, 2014 at 01:57:04PM -0700, David Lang wrote: On Tue, 1 Apr 2014, Jason Cooper wrote: >> Now I guess we need to think how to make it work without a >> framebuffer. I already suggested using the ASCII characters, >> but seeing the resolution of this QR code for example (147x147), >> made me realize that we can't shuffle that into a 80x25 textmode >> display. Any ideas how to fix that or should we just simply depend >> on a framebuffer being present? > > I think depending on the framebuffer being present (via kconfig) is > sane. Folks running old systems know what they're in for, like missing > shiny new features. ;-) First get it working and into acceptable form, but after that, take a look at the various ASCII-art tools out there. While the display may be limited to 80x25, that's not a hard requirement (and I'd happily run systems with a smaller text console if this was an option), and then you can look at the possibility of using characters that represent more than one pixel per character. While this may not be able to render everything perfectly, remember that qr codes can include redundancy to correct for bad pixels, you may be able to get something working. >> >> I am not sure depending on the error recovery is good practice. >> We also have to take into account that scanners themselves also >> create noise and may not be perfect. Better reserve the error >> recovery for those details instead of messing the QR code with >> characters... > > You do have the option of error recovery for up to 30% recovery (H > level), but that means the space you get for storing is smaller. > >> >>> >>> I'm not sure this will work. The screen space allocated to a single >>> character isn't square. However, the QR pixels are square. I see a lot >>> of fragile complexity ahead... >>> >> >> ... not to mention this as well. >> >> >> IMHO supporting textmode is just not worth the effort. Besides, >> what would we gain from it? Supporting those devices without >> a framebuffer? Do devices like that even exist anymore? In fact, >> even to make this you need a screen, and AFAIK most screens come >> with some kind of a framebuffer to drive them. > > Guys, first things first is cleaning the library up. I haven't managed > to do anything yet as I am working on my thesis (bachelor's degree, > yay!). I will do some this weekend and that is removing the kanji mode > support. So, Levente, pleaso do that parameter thing you mentioned. > Merging that with the cleanup shouldn't be a problem. :-) Awesome, good luck on your thesis, take your time, we are not rushing. :-) Yea, I began the work on the parameter and scaling but using 'oops.qr=' isn't easy to use in a file called 'print_oops.c'. Reason is that KBUILD_MODNAME will become 'print_oops' and then MODULE_PARAM_PREFIX will be 'print_oops.' (note the dot character) and so the final parameter will be 'print_oops.qr'. I have solved this with: #undef MODULE_PARAM_PREFIX #define MODULE_PARAM_PREFIX "oops." but I think this is ugly and is a hack. The good solution would be to change KBUILD_MODNAME to 'oops' but I am not sure how to do that, since I have little to no knowledge (and experience) in how kbuild works. Or, we could use core_param and simply have 'oops_qr' or 'qr_oops'. In my humble opinion the latter sounds better. Or, there is __setup as well and that could achieve 'oops.qr', but that is for *very* core stuff and this is probably not *that* core. :-) So, yea, if anyone knows how to change KBUILD_MODNAME without ugly hacks, I would be grateful to be informed. > > I think writing the QR to the frame buffer is the way to do it for > now. Doing a QR in text mode (as in displaying it, not as previously > mentioned idea with the link base64 encoding &/ compression) would > mean that for each square you get an ASCII character filling up your > screen. To get an idea of how the QR looks on the frame buffer I've > made a screenshot. That's the whole Oops message being encoded and > compressed. [0] I am not sure if we ever wanted to output a link, but yes filling the screen with ASCII characters and relying on the error recovery to ensure readability is very bad. Nice screenshot, I had as well successfully set up a testsuite with qemu that allows me to test if it displays correctly. I can share the testsuite if needed. > > The problem with frame buffer is that I currently implemented it using > the generic frame buffer API. There are some issues as mentioned in > the first post of this RFC [1]. Would making it work with KMS be > better? Any opinions? Not sure, since we are already in a very bad situation when the Oops happens, I think it is better use something that has existed for ages
Re: [RFC] QR encoding for Oops messages
Hi, On 04/04/2014 11:42 PM, Teodora Băluţă wrote: On Fri, Apr 4, 2014 at 7:17 PM, Levente Kurusa le...@linux.com wrote: Hi, On 04/04/2014 05:15 PM, Jason Cooper wrote: On Thu, Apr 03, 2014 at 01:57:04PM -0700, David Lang wrote: On Tue, 1 Apr 2014, Jason Cooper wrote: Now I guess we need to think how to make it work without a framebuffer. I already suggested using the ASCII characters, but seeing the resolution of this QR code for example (147x147), made me realize that we can't shuffle that into a 80x25 textmode display. Any ideas how to fix that or should we just simply depend on a framebuffer being present? I think depending on the framebuffer being present (via kconfig) is sane. Folks running old systems know what they're in for, like missing shiny new features. ;-) First get it working and into acceptable form, but after that, take a look at the various ASCII-art tools out there. While the display may be limited to 80x25, that's not a hard requirement (and I'd happily run systems with a smaller text console if this was an option), and then you can look at the possibility of using characters that represent more than one pixel per character. While this may not be able to render everything perfectly, remember that qr codes can include redundancy to correct for bad pixels, you may be able to get something working. I am not sure depending on the error recovery is good practice. We also have to take into account that scanners themselves also create noise and may not be perfect. Better reserve the error recovery for those details instead of messing the QR code with characters... You do have the option of error recovery for up to 30% recovery (H level), but that means the space you get for storing is smaller. I'm not sure this will work. The screen space allocated to a single character isn't square. However, the QR pixels are square. I see a lot of fragile complexity ahead... ... not to mention this as well. IMHO supporting textmode is just not worth the effort. Besides, what would we gain from it? Supporting those devices without a framebuffer? Do devices like that even exist anymore? In fact, even to make this you need a screen, and AFAIK most screens come with some kind of a framebuffer to drive them. Guys, first things first is cleaning the library up. I haven't managed to do anything yet as I am working on my thesis (bachelor's degree, yay!). I will do some this weekend and that is removing the kanji mode support. So, Levente, pleaso do that parameter thing you mentioned. Merging that with the cleanup shouldn't be a problem. :-) Awesome, good luck on your thesis, take your time, we are not rushing. :-) Yea, I began the work on the parameter and scaling but using 'oops.qr=' isn't easy to use in a file called 'print_oops.c'. Reason is that KBUILD_MODNAME will become 'print_oops' and then MODULE_PARAM_PREFIX will be 'print_oops.' (note the dot character) and so the final parameter will be 'print_oops.qr'. I have solved this with: #undef MODULE_PARAM_PREFIX #define MODULE_PARAM_PREFIX oops. but I think this is ugly and is a hack. The good solution would be to change KBUILD_MODNAME to 'oops' but I am not sure how to do that, since I have little to no knowledge (and experience) in how kbuild works. Or, we could use core_param and simply have 'oops_qr' or 'qr_oops'. In my humble opinion the latter sounds better. Or, there is __setup as well and that could achieve 'oops.qr', but that is for *very* core stuff and this is probably not *that* core. :-) So, yea, if anyone knows how to change KBUILD_MODNAME without ugly hacks, I would be grateful to be informed. I think writing the QR to the frame buffer is the way to do it for now. Doing a QR in text mode (as in displaying it, not as previously mentioned idea with the link base64 encoding / compression) would mean that for each square you get an ASCII character filling up your screen. To get an idea of how the QR looks on the frame buffer I've made a screenshot. That's the whole Oops message being encoded and compressed. [0] I am not sure if we ever wanted to output a link, but yes filling the screen with ASCII characters and relying on the error recovery to ensure readability is very bad. Nice screenshot, I had as well successfully set up a testsuite with qemu that allows me to test if it displays correctly. I can share the testsuite if needed. The problem with frame buffer is that I currently implemented it using the generic frame buffer API. There are some issues as mentioned in the first post of this RFC [1]. Would making it work with KMS be better? Any opinions? Not sure, since we are already in a very bad situation when the Oops happens, I think it is better use something that has existed for ages and seems to be a bit more simple, and has less chance to fail. Adding a lot of new code to a fragile part of the kernel is a hotbed for a recursive oops so I would say just
Re: [RFC] QR encoding for Oops messages
On Fri, Apr 4, 2014 at 7:17 PM, Levente Kurusa wrote: > Hi, > > On 04/04/2014 05:15 PM, Jason Cooper wrote: >> On Thu, Apr 03, 2014 at 01:57:04PM -0700, David Lang wrote: >>> On Tue, 1 Apr 2014, Jason Cooper wrote: >>> > Now I guess we need to think how to make it work without a > framebuffer. I already suggested using the ASCII characters, > but seeing the resolution of this QR code for example (147x147), > made me realize that we can't shuffle that into a 80x25 textmode > display. Any ideas how to fix that or should we just simply depend > on a framebuffer being present? I think depending on the framebuffer being present (via kconfig) is sane. Folks running old systems know what they're in for, like missing shiny new features. ;-) >>> >>> First get it working and into acceptable form, but after that, take >>> a look at the various ASCII-art tools out there. While the display >>> may be limited to 80x25, that's not a hard requirement (and I'd >>> happily run systems with a smaller text console if this was an >>> option), and then you can look at the possibility of using >>> characters that represent more than one pixel per character. While >>> this may not be able to render everything perfectly, remember that >>> qr codes can include redundancy to correct for bad pixels, you may >>> be able to get something working. > > I am not sure depending on the error recovery is good practice. > We also have to take into account that scanners themselves also > create noise and may not be perfect. Better reserve the error > recovery for those details instead of messing the QR code with > characters... You do have the option of error recovery for up to 30% recovery (H level), but that means the space you get for storing is smaller. > >> >> I'm not sure this will work. The screen space allocated to a single >> character isn't square. However, the QR pixels are square. I see a lot >> of fragile complexity ahead... >> > > ... not to mention this as well. > > > IMHO supporting textmode is just not worth the effort. Besides, > what would we gain from it? Supporting those devices without > a framebuffer? Do devices like that even exist anymore? In fact, > even to make this you need a screen, and AFAIK most screens come > with some kind of a framebuffer to drive them. Guys, first things first is cleaning the library up. I haven't managed to do anything yet as I am working on my thesis (bachelor's degree, yay!). I will do some this weekend and that is removing the kanji mode support. So, Levente, pleaso do that parameter thing you mentioned. Merging that with the cleanup shouldn't be a problem. :-) I think writing the QR to the frame buffer is the way to do it for now. Doing a QR in text mode (as in displaying it, not as previously mentioned idea with the link base64 encoding &/ compression) would mean that for each square you get an ASCII character filling up your screen. To get an idea of how the QR looks on the frame buffer I've made a screenshot. That's the whole Oops message being encoded and compressed. [0] The problem with frame buffer is that I currently implemented it using the generic frame buffer API. There are some issues as mentioned in the first post of this RFC [1]. Would making it work with KMS be better? Any opinions? Thanks, -- Teodora [0] http://swarm.cs.pub.ro/~teobaluta/QR_code_fb.jpg [1] https://lkml.org/lkml/2014/3/17/525 > > -- > Regards, > Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
Hi, On 04/04/2014 05:15 PM, Jason Cooper wrote: > On Thu, Apr 03, 2014 at 01:57:04PM -0700, David Lang wrote: >> On Tue, 1 Apr 2014, Jason Cooper wrote: >> Now I guess we need to think how to make it work without a framebuffer. I already suggested using the ASCII characters, but seeing the resolution of this QR code for example (147x147), made me realize that we can't shuffle that into a 80x25 textmode display. Any ideas how to fix that or should we just simply depend on a framebuffer being present? >>> >>> I think depending on the framebuffer being present (via kconfig) is >>> sane. Folks running old systems know what they're in for, like missing >>> shiny new features. ;-) >> >> First get it working and into acceptable form, but after that, take >> a look at the various ASCII-art tools out there. While the display >> may be limited to 80x25, that's not a hard requirement (and I'd >> happily run systems with a smaller text console if this was an >> option), and then you can look at the possibility of using >> characters that represent more than one pixel per character. While >> this may not be able to render everything perfectly, remember that >> qr codes can include redundancy to correct for bad pixels, you may >> be able to get something working. I am not sure depending on the error recovery is good practice. We also have to take into account that scanners themselves also create noise and may not be perfect. Better reserve the error recovery for those details instead of messing the QR code with characters... > > I'm not sure this will work. The screen space allocated to a single > character isn't square. However, the QR pixels are square. I see a lot > of fragile complexity ahead... > ... not to mention this as well. IMHO supporting textmode is just not worth the effort. Besides, what would we gain from it? Supporting those devices without a framebuffer? Do devices like that even exist anymore? In fact, even to make this you need a screen, and AFAIK most screens come with some kind of a framebuffer to drive them. -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
Hi, On 04/04/2014 05:12 PM, Jason Cooper wrote: > On Thu, Apr 03, 2014 at 10:21:39PM +0200, Levente Kurusa wrote: > ... >> Oh and I had an idea of adding a new kernel parameter, something >> like 'qr_oops.*'. (Looking for a better name! :-) ) >> Basically, I thought of the following options so far: >> >> * qr_oops.disable=1 - disable it >> * qr_oops.scale=600x600 - scale the qr code so its easier to read >>with a phone. In my testing I had huge difficulties reading the >>QR codes, but when scaled to be a bit bigger it worked magically. >>This might not be so easy to implement this way, but with preset >>values, i.e. 4x4 squares instead of a pixel, it could work. > > oops.qr=0 - disabled > oops.qr=3 - make each QR pixel 3x3 screen pixels. > > I've found 3x3 works well for business cards and such. > Yea this makes more sense. I'll go and implement this right now and send the changes to Teodora once finished. -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Thu, Apr 03, 2014 at 01:57:04PM -0700, David Lang wrote: > On Tue, 1 Apr 2014, Jason Cooper wrote: > > >>Now I guess we need to think how to make it work without a > >>framebuffer. I already suggested using the ASCII characters, > >>but seeing the resolution of this QR code for example (147x147), > >>made me realize that we can't shuffle that into a 80x25 textmode > >>display. Any ideas how to fix that or should we just simply depend > >>on a framebuffer being present? > > > >I think depending on the framebuffer being present (via kconfig) is > >sane. Folks running old systems know what they're in for, like missing > >shiny new features. ;-) > > First get it working and into acceptable form, but after that, take > a look at the various ASCII-art tools out there. While the display > may be limited to 80x25, that's not a hard requirement (and I'd > happily run systems with a smaller text console if this was an > option), and then you can look at the possibility of using > characters that represent more than one pixel per character. While > this may not be able to render everything perfectly, remember that > qr codes can include redundancy to correct for bad pixels, you may > be able to get something working. I'm not sure this will work. The screen space allocated to a single character isn't square. However, the QR pixels are square. I see a lot of fragile complexity ahead... thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Thu, Apr 03, 2014 at 10:21:39PM +0200, Levente Kurusa wrote: ... > Oh and I had an idea of adding a new kernel parameter, something > like 'qr_oops.*'. (Looking for a better name! :-) ) > Basically, I thought of the following options so far: > > * qr_oops.disable=1 - disable it > * qr_oops.scale=600x600 - scale the qr code so its easier to read >with a phone. In my testing I had huge difficulties reading the >QR codes, but when scaled to be a bit bigger it worked magically. >This might not be so easy to implement this way, but with preset >values, i.e. 4x4 squares instead of a pixel, it could work. oops.qr=0 - disabled oops.qr=3 - make each QR pixel 3x3 screen pixels. I've found 3x3 works well for business cards and such. 0.02c... thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Thu, Apr 03, 2014 at 10:21:39PM +0200, Levente Kurusa wrote: ... Oh and I had an idea of adding a new kernel parameter, something like 'qr_oops.*'. (Looking for a better name! :-) ) Basically, I thought of the following options so far: * qr_oops.disable=1 - disable it * qr_oops.scale=600x600 - scale the qr code so its easier to read with a phone. In my testing I had huge difficulties reading the QR codes, but when scaled to be a bit bigger it worked magically. This might not be so easy to implement this way, but with preset values, i.e. 4x4 squares instead of a pixel, it could work. oops.qr=0 - disabled oops.qr=3 - make each QR pixel 3x3 screen pixels. I've found 3x3 works well for business cards and such. 0.02c... thx, Jason. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Thu, Apr 03, 2014 at 01:57:04PM -0700, David Lang wrote: On Tue, 1 Apr 2014, Jason Cooper wrote: Now I guess we need to think how to make it work without a framebuffer. I already suggested using the ASCII characters, but seeing the resolution of this QR code for example (147x147), made me realize that we can't shuffle that into a 80x25 textmode display. Any ideas how to fix that or should we just simply depend on a framebuffer being present? I think depending on the framebuffer being present (via kconfig) is sane. Folks running old systems know what they're in for, like missing shiny new features. ;-) First get it working and into acceptable form, but after that, take a look at the various ASCII-art tools out there. While the display may be limited to 80x25, that's not a hard requirement (and I'd happily run systems with a smaller text console if this was an option), and then you can look at the possibility of using characters that represent more than one pixel per character. While this may not be able to render everything perfectly, remember that qr codes can include redundancy to correct for bad pixels, you may be able to get something working. I'm not sure this will work. The screen space allocated to a single character isn't square. However, the QR pixels are square. I see a lot of fragile complexity ahead... thx, Jason. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
Hi, On 04/04/2014 05:12 PM, Jason Cooper wrote: On Thu, Apr 03, 2014 at 10:21:39PM +0200, Levente Kurusa wrote: ... Oh and I had an idea of adding a new kernel parameter, something like 'qr_oops.*'. (Looking for a better name! :-) ) Basically, I thought of the following options so far: * qr_oops.disable=1 - disable it * qr_oops.scale=600x600 - scale the qr code so its easier to read with a phone. In my testing I had huge difficulties reading the QR codes, but when scaled to be a bit bigger it worked magically. This might not be so easy to implement this way, but with preset values, i.e. 4x4 squares instead of a pixel, it could work. oops.qr=0 - disabled oops.qr=3 - make each QR pixel 3x3 screen pixels. I've found 3x3 works well for business cards and such. Yea this makes more sense. I'll go and implement this right now and send the changes to Teodora once finished. -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
Hi, On 04/04/2014 05:15 PM, Jason Cooper wrote: On Thu, Apr 03, 2014 at 01:57:04PM -0700, David Lang wrote: On Tue, 1 Apr 2014, Jason Cooper wrote: Now I guess we need to think how to make it work without a framebuffer. I already suggested using the ASCII characters, but seeing the resolution of this QR code for example (147x147), made me realize that we can't shuffle that into a 80x25 textmode display. Any ideas how to fix that or should we just simply depend on a framebuffer being present? I think depending on the framebuffer being present (via kconfig) is sane. Folks running old systems know what they're in for, like missing shiny new features. ;-) First get it working and into acceptable form, but after that, take a look at the various ASCII-art tools out there. While the display may be limited to 80x25, that's not a hard requirement (and I'd happily run systems with a smaller text console if this was an option), and then you can look at the possibility of using characters that represent more than one pixel per character. While this may not be able to render everything perfectly, remember that qr codes can include redundancy to correct for bad pixels, you may be able to get something working. I am not sure depending on the error recovery is good practice. We also have to take into account that scanners themselves also create noise and may not be perfect. Better reserve the error recovery for those details instead of messing the QR code with characters... I'm not sure this will work. The screen space allocated to a single character isn't square. However, the QR pixels are square. I see a lot of fragile complexity ahead... ... not to mention this as well. IMHO supporting textmode is just not worth the effort. Besides, what would we gain from it? Supporting those devices without a framebuffer? Do devices like that even exist anymore? In fact, even to make this you need a screen, and AFAIK most screens come with some kind of a framebuffer to drive them. -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Fri, Apr 4, 2014 at 7:17 PM, Levente Kurusa le...@linux.com wrote: Hi, On 04/04/2014 05:15 PM, Jason Cooper wrote: On Thu, Apr 03, 2014 at 01:57:04PM -0700, David Lang wrote: On Tue, 1 Apr 2014, Jason Cooper wrote: Now I guess we need to think how to make it work without a framebuffer. I already suggested using the ASCII characters, but seeing the resolution of this QR code for example (147x147), made me realize that we can't shuffle that into a 80x25 textmode display. Any ideas how to fix that or should we just simply depend on a framebuffer being present? I think depending on the framebuffer being present (via kconfig) is sane. Folks running old systems know what they're in for, like missing shiny new features. ;-) First get it working and into acceptable form, but after that, take a look at the various ASCII-art tools out there. While the display may be limited to 80x25, that's not a hard requirement (and I'd happily run systems with a smaller text console if this was an option), and then you can look at the possibility of using characters that represent more than one pixel per character. While this may not be able to render everything perfectly, remember that qr codes can include redundancy to correct for bad pixels, you may be able to get something working. I am not sure depending on the error recovery is good practice. We also have to take into account that scanners themselves also create noise and may not be perfect. Better reserve the error recovery for those details instead of messing the QR code with characters... You do have the option of error recovery for up to 30% recovery (H level), but that means the space you get for storing is smaller. I'm not sure this will work. The screen space allocated to a single character isn't square. However, the QR pixels are square. I see a lot of fragile complexity ahead... ... not to mention this as well. IMHO supporting textmode is just not worth the effort. Besides, what would we gain from it? Supporting those devices without a framebuffer? Do devices like that even exist anymore? In fact, even to make this you need a screen, and AFAIK most screens come with some kind of a framebuffer to drive them. Guys, first things first is cleaning the library up. I haven't managed to do anything yet as I am working on my thesis (bachelor's degree, yay!). I will do some this weekend and that is removing the kanji mode support. So, Levente, pleaso do that parameter thing you mentioned. Merging that with the cleanup shouldn't be a problem. :-) I think writing the QR to the frame buffer is the way to do it for now. Doing a QR in text mode (as in displaying it, not as previously mentioned idea with the link base64 encoding / compression) would mean that for each square you get an ASCII character filling up your screen. To get an idea of how the QR looks on the frame buffer I've made a screenshot. That's the whole Oops message being encoded and compressed. [0] The problem with frame buffer is that I currently implemented it using the generic frame buffer API. There are some issues as mentioned in the first post of this RFC [1]. Would making it work with KMS be better? Any opinions? Thanks, -- Teodora [0] http://swarm.cs.pub.ro/~teobaluta/QR_code_fb.jpg [1] https://lkml.org/lkml/2014/3/17/525 -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Tue, 1 Apr 2014, Jason Cooper wrote: Now I guess we need to think how to make it work without a framebuffer. I already suggested using the ASCII characters, but seeing the resolution of this QR code for example (147x147), made me realize that we can't shuffle that into a 80x25 textmode display. Any ideas how to fix that or should we just simply depend on a framebuffer being present? I think depending on the framebuffer being present (via kconfig) is sane. Folks running old systems know what they're in for, like missing shiny new features. ;-) First get it working and into acceptable form, but after that, take a look at the various ASCII-art tools out there. While the display may be limited to 80x25, that's not a hard requirement (and I'd happily run systems with a smaller text console if this was an option), and then you can look at the possibility of using characters that represent more than one pixel per character. While this may not be able to render everything perfectly, remember that qr codes can include redundancy to correct for bad pixels, you may be able to get something working. David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
Hi, 2014-04-01 23:07 GMT+02:00 Teodora Băluţă : > On Tue, Apr 1, 2014 at 5:20 PM, Jason Cooper wrote: >> On Sun, Mar 30, 2014 at 12:17:17PM +0200, Levente Kurusa wrote: >>> Hi all, >>> >>> (sorry for the late reply, looks like this mail has ran away from my >>> clients) > > same here. > >>> >>> 2014-03-23 20:38 GMT+01:00 Jason Cooper : >>> > All, >>> > >>> > On Sat, Mar 22, 2014 at 08:20:01PM +0200, Teodora Băluţă wrote: >>> >> On Sat, Mar 22, 2014 at 7:09 PM, Levente Kurusa wrote: >>> >> > On 03/21/2014 02:28 PM, Jason Cooper wrote: >>> > ... >>> >> >> 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. >>> >> > >>> >> > I still struggle to understand how could that be done. We can encode >>> >> > the >>> >> > QR code as ASCII. Okay, that's fine, however it is very long. Encoding >>> >> > 'Unable to handle kernel paging request at 000f' gave a 449 >>> >> > character >>> >> > long sequence with very strange characters [0]. We should try to >>> >> > shorten >>> >> > it, imho. Not sure how to do that though. >>> > >>> > The man page for qrencode says you can have up to 4000 characters in a >>> > qrcode. However, I've seen readers have trouble with a 2048bit ascii >>> > armored PGP public key (3929 characters). >>> > >>> > I grabbed a random oops from oops.kernel.org, it weighed in at 1544 >>> > bytes, not too bad. I then did: >>> > >>> > $ echo "https://oops.kernel.org/?qr=`cat oops.txt | gzip -9 | base64 >>> > -wrap=0`" | wc -c >>> > 993 >>> >>> I did the same with another OOPS and it had 1953 characters. That's quite a >>> big >>> a big difference! :-) >>> >>> I created a QR image from the URL then, and it was 147x147, which is >>> pretty small. >>> It took me quite a long time to make my phone recognize it, but it >>> worked nicely. >>> >>> Result of work is in this directory: >>> >>> http://levex.fedorapeople.org/kernel/qr/ >> >> nice! >> >>> > The benefit of a url is that any QR reader can automagically report an >>> > oops. While a specific app could parse the URL/oops locally if the >>> > user desires. >>> > >>> >> it misses the point of having a QR code in the first place. The way I >>> >> see it, having a QR decoder app installed that can do an offline >>> >> decoding is a less greater effort than popping out a browser on the >>> >> machine you're working on. >>> > >>> > I think you're selling the advantage of the QR code short. Automated >>> > reporting (via the url) is a _huge_ plus. The app you conceive of could >>> > still parse it in place if the user desires. >>> > >>> > My point for the URL isn't to use the internet/server to automate oops >>> > parsing for the user. Rather it's to make it easy to report oopses to >>> > developers. While still preserving the ability of your app to parse it >>> > for the user. >>> >>> Ah I see now. oops.kernel.org/?qr= would simply parse the >>> base64'd+gzip'd oops message and then report it. >> >> If you mean the server behind oops.k.o would parse it, then yes. No >> special app should be required other than a QR code scanner for the >> usecase of reporting oopses to developers. Yup, clear now. >> >>> Now I guess we need to think how to make it work without a >>> framebuffer. I already suggested using the ASCII characters, >>> but seeing the resolution of this QR code for example (147x147), >>> made me realize that we can't shuffle that into a 80x25 textmode >>> display. Any ideas how to fix that or should we just simply depend >>> on a framebuffer being present? >> >> I think depending on the framebuffer being present (via kconfig) is >> sane. Folks running old systems know what they're in for, like missing >> shiny new features. ;-) > > Ok, this may work. I agree that doing this with the help of the frame > buffer is more natural. Okay, Teodora I'll send you a commit ASAP and then we should start working on getting libqr into an acceptable state. I am not sure if we can shuffle it into staging though, it's not a driver and AFAIK staging.git is for drivers which aren't yet finished. So, I would say, let's start working on fixing the OOPness of libqr first. If we were to rework that, then we can as well avoid having GFP_ATOMIC in library code by using the more conventional kmalloc(struct); init_struct(ptr); scheme. Oh and I had an idea of adding a new kernel parameter, something like 'qr_oops.*'. (Looking for a better name! :-) ) Basically, I thought of the following options so far: * qr_oops.disable=1 - disable it * qr_oops.scale=600x600 - scale the qr code so its easier to read with a phone. In my testing I had huge difficulties reading the QR codes, but when scaled to be a bit bigger it worked magically. This might not be so easy to implement this way, but with preset values, i.e. 4x4 squares instead of a pixel, it could work. Objections, ideas are welcome! Teodora,
Re: [RFC] QR encoding for Oops messages
Hi, 2014-04-01 23:07 GMT+02:00 Teodora Băluţă teobal...@gmail.com: On Tue, Apr 1, 2014 at 5:20 PM, Jason Cooper ja...@lakedaemon.net wrote: On Sun, Mar 30, 2014 at 12:17:17PM +0200, Levente Kurusa wrote: Hi all, (sorry for the late reply, looks like this mail has ran away from my clients) same here. 2014-03-23 20:38 GMT+01:00 Jason Cooper ja...@lakedaemon.net: All, On Sat, Mar 22, 2014 at 08:20:01PM +0200, Teodora Băluţă wrote: On Sat, Mar 22, 2014 at 7:09 PM, Levente Kurusa le...@linux.com wrote: On 03/21/2014 02:28 PM, Jason Cooper wrote: ... 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. I still struggle to understand how could that be done. We can encode the QR code as ASCII. Okay, that's fine, however it is very long. Encoding 'Unable to handle kernel paging request at 000f' gave a 449 character long sequence with very strange characters [0]. We should try to shorten it, imho. Not sure how to do that though. The man page for qrencode says you can have up to 4000 characters in a qrcode. However, I've seen readers have trouble with a 2048bit ascii armored PGP public key (3929 characters). I grabbed a random oops from oops.kernel.org, it weighed in at 1544 bytes, not too bad. I then did: $ echo https://oops.kernel.org/?qr=`cat oops.txt | gzip -9 | base64 -wrap=0` | wc -c 993 I did the same with another OOPS and it had 1953 characters. That's quite a big a big difference! :-) I created a QR image from the URL then, and it was 147x147, which is pretty small. It took me quite a long time to make my phone recognize it, but it worked nicely. Result of work is in this directory: http://levex.fedorapeople.org/kernel/qr/ nice! The benefit of a url is that any QR reader can automagically report an oops. While a specific app could parse the URL/oops locally if the user desires. it misses the point of having a QR code in the first place. The way I see it, having a QR decoder app installed that can do an offline decoding is a less greater effort than popping out a browser on the machine you're working on. I think you're selling the advantage of the QR code short. Automated reporting (via the url) is a _huge_ plus. The app you conceive of could still parse it in place if the user desires. My point for the URL isn't to use the internet/server to automate oops parsing for the user. Rather it's to make it easy to report oopses to developers. While still preserving the ability of your app to parse it for the user. Ah I see now. oops.kernel.org/?qr=QR would simply parse the base64'd+gzip'd oops message and then report it. If you mean the server behind oops.k.o would parse it, then yes. No special app should be required other than a QR code scanner for the usecase of reporting oopses to developers. Yup, clear now. Now I guess we need to think how to make it work without a framebuffer. I already suggested using the ASCII characters, but seeing the resolution of this QR code for example (147x147), made me realize that we can't shuffle that into a 80x25 textmode display. Any ideas how to fix that or should we just simply depend on a framebuffer being present? I think depending on the framebuffer being present (via kconfig) is sane. Folks running old systems know what they're in for, like missing shiny new features. ;-) Ok, this may work. I agree that doing this with the help of the frame buffer is more natural. Okay, Teodora I'll send you a commit ASAP and then we should start working on getting libqr into an acceptable state. I am not sure if we can shuffle it into staging though, it's not a driver and AFAIK staging.git is for drivers which aren't yet finished. So, I would say, let's start working on fixing the OOPness of libqr first. If we were to rework that, then we can as well avoid having GFP_ATOMIC in library code by using the more conventional kmalloc(struct); init_struct(ptr); scheme. Oh and I had an idea of adding a new kernel parameter, something like 'qr_oops.*'. (Looking for a better name! :-) ) Basically, I thought of the following options so far: * qr_oops.disable=1 - disable it * qr_oops.scale=600x600 - scale the qr code so its easier to read with a phone. In my testing I had huge difficulties reading the QR codes, but when scaled to be a bit bigger it worked magically. This might not be so easy to implement this way, but with preset values, i.e. 4x4 squares instead of a pixel, it could work. Objections, ideas are welcome! Teodora, have you worked on anything recently in qr-linux-kernel? Just to make sure we aren't working on the same. Thanks, Levente Kurusa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More
Re: [RFC] QR encoding for Oops messages
On Tue, 1 Apr 2014, Jason Cooper wrote: Now I guess we need to think how to make it work without a framebuffer. I already suggested using the ASCII characters, but seeing the resolution of this QR code for example (147x147), made me realize that we can't shuffle that into a 80x25 textmode display. Any ideas how to fix that or should we just simply depend on a framebuffer being present? I think depending on the framebuffer being present (via kconfig) is sane. Folks running old systems know what they're in for, like missing shiny new features. ;-) First get it working and into acceptable form, but after that, take a look at the various ASCII-art tools out there. While the display may be limited to 80x25, that's not a hard requirement (and I'd happily run systems with a smaller text console if this was an option), and then you can look at the possibility of using characters that represent more than one pixel per character. While this may not be able to render everything perfectly, remember that qr codes can include redundancy to correct for bad pixels, you may be able to get something working. David Lang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Tue, Apr 1, 2014 at 5:20 PM, Jason Cooper wrote: > On Sun, Mar 30, 2014 at 12:17:17PM +0200, Levente Kurusa wrote: >> Hi all, >> >> (sorry for the late reply, looks like this mail has ran away from my clients) same here. >> >> 2014-03-23 20:38 GMT+01:00 Jason Cooper : >> > All, >> > >> > On Sat, Mar 22, 2014 at 08:20:01PM +0200, Teodora Băluţă wrote: >> >> On Sat, Mar 22, 2014 at 7:09 PM, Levente Kurusa wrote: >> >> > On 03/21/2014 02:28 PM, Jason Cooper wrote: >> > ... >> >> >> 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. >> >> > >> >> > I still struggle to understand how could that be done. We can encode the >> >> > QR code as ASCII. Okay, that's fine, however it is very long. Encoding >> >> > 'Unable to handle kernel paging request at 000f' gave a 449 >> >> > character >> >> > long sequence with very strange characters [0]. We should try to shorten >> >> > it, imho. Not sure how to do that though. >> > >> > The man page for qrencode says you can have up to 4000 characters in a >> > qrcode. However, I've seen readers have trouble with a 2048bit ascii >> > armored PGP public key (3929 characters). >> > >> > I grabbed a random oops from oops.kernel.org, it weighed in at 1544 >> > bytes, not too bad. I then did: >> > >> > $ echo "https://oops.kernel.org/?qr=`cat oops.txt | gzip -9 | base64 >> > -wrap=0`" | wc -c >> > 993 >> >> I did the same with another OOPS and it had 1953 characters. That's quite a >> big >> a big difference! :-) >> >> I created a QR image from the URL then, and it was 147x147, which is >> pretty small. >> It took me quite a long time to make my phone recognize it, but it >> worked nicely. >> >> Result of work is in this directory: >> >> http://levex.fedorapeople.org/kernel/qr/ > > nice! > >> > The benefit of a url is that any QR reader can automagically report an >> > oops. While a specific app could parse the URL/oops locally if the >> > user desires. >> > >> >> it misses the point of having a QR code in the first place. The way I >> >> see it, having a QR decoder app installed that can do an offline >> >> decoding is a less greater effort than popping out a browser on the >> >> machine you're working on. >> > >> > I think you're selling the advantage of the QR code short. Automated >> > reporting (via the url) is a _huge_ plus. The app you conceive of could >> > still parse it in place if the user desires. >> > >> > My point for the URL isn't to use the internet/server to automate oops >> > parsing for the user. Rather it's to make it easy to report oopses to >> > developers. While still preserving the ability of your app to parse it >> > for the user. >> >> Ah I see now. oops.kernel.org/?qr= would simply parse the >> base64'd+gzip'd oops message and then report it. > > If you mean the server behind oops.k.o would parse it, then yes. No > special app should be required other than a QR code scanner for the > usecase of reporting oopses to developers. > >> Now I guess we need to think how to make it work without a >> framebuffer. I already suggested using the ASCII characters, >> but seeing the resolution of this QR code for example (147x147), >> made me realize that we can't shuffle that into a 80x25 textmode >> display. Any ideas how to fix that or should we just simply depend >> on a framebuffer being present? > > I think depending on the framebuffer being present (via kconfig) is > sane. Folks running old systems know what they're in for, like missing > shiny new features. ;-) Ok, this may work. I agree that doing this with the help of the frame buffer is more natural. Thanks, -- Teodora > > thx, > > Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Sun, Mar 30, 2014 at 12:17:17PM +0200, Levente Kurusa wrote: > Hi all, > > (sorry for the late reply, looks like this mail has ran away from my clients) > > 2014-03-23 20:38 GMT+01:00 Jason Cooper : > > All, > > > > On Sat, Mar 22, 2014 at 08:20:01PM +0200, Teodora Băluţă wrote: > >> On Sat, Mar 22, 2014 at 7:09 PM, Levente Kurusa wrote: > >> > On 03/21/2014 02:28 PM, Jason Cooper wrote: > > ... > >> >> 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. > >> > > >> > I still struggle to understand how could that be done. We can encode the > >> > QR code as ASCII. Okay, that's fine, however it is very long. Encoding > >> > 'Unable to handle kernel paging request at 000f' gave a 449 character > >> > long sequence with very strange characters [0]. We should try to shorten > >> > it, imho. Not sure how to do that though. > > > > The man page for qrencode says you can have up to 4000 characters in a > > qrcode. However, I've seen readers have trouble with a 2048bit ascii > > armored PGP public key (3929 characters). > > > > I grabbed a random oops from oops.kernel.org, it weighed in at 1544 > > bytes, not too bad. I then did: > > > > $ echo "https://oops.kernel.org/?qr=`cat oops.txt | gzip -9 | base64 > > -wrap=0`" | wc -c > > 993 > > I did the same with another OOPS and it had 1953 characters. That's quite a > big > a big difference! :-) > > I created a QR image from the URL then, and it was 147x147, which is > pretty small. > It took me quite a long time to make my phone recognize it, but it > worked nicely. > > Result of work is in this directory: > > http://levex.fedorapeople.org/kernel/qr/ nice! > > The benefit of a url is that any QR reader can automagically report an > > oops. While a specific app could parse the URL/oops locally if the > > user desires. > > > >> it misses the point of having a QR code in the first place. The way I > >> see it, having a QR decoder app installed that can do an offline > >> decoding is a less greater effort than popping out a browser on the > >> machine you're working on. > > > > I think you're selling the advantage of the QR code short. Automated > > reporting (via the url) is a _huge_ plus. The app you conceive of could > > still parse it in place if the user desires. > > > > My point for the URL isn't to use the internet/server to automate oops > > parsing for the user. Rather it's to make it easy to report oopses to > > developers. While still preserving the ability of your app to parse it > > for the user. > > Ah I see now. oops.kernel.org/?qr= would simply parse the > base64'd+gzip'd oops message and then report it. If you mean the server behind oops.k.o would parse it, then yes. No special app should be required other than a QR code scanner for the usecase of reporting oopses to developers. > Now I guess we need to think how to make it work without a > framebuffer. I already suggested using the ASCII characters, > but seeing the resolution of this QR code for example (147x147), > made me realize that we can't shuffle that into a 80x25 textmode > display. Any ideas how to fix that or should we just simply depend > on a framebuffer being present? I think depending on the framebuffer being present (via kconfig) is sane. Folks running old systems know what they're in for, like missing shiny new features. ;-) thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Sun, Mar 30, 2014 at 12:17:17PM +0200, Levente Kurusa wrote: Hi all, (sorry for the late reply, looks like this mail has ran away from my clients) 2014-03-23 20:38 GMT+01:00 Jason Cooper ja...@lakedaemon.net: All, On Sat, Mar 22, 2014 at 08:20:01PM +0200, Teodora Băluţă wrote: On Sat, Mar 22, 2014 at 7:09 PM, Levente Kurusa le...@linux.com wrote: On 03/21/2014 02:28 PM, Jason Cooper wrote: ... 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. I still struggle to understand how could that be done. We can encode the QR code as ASCII. Okay, that's fine, however it is very long. Encoding 'Unable to handle kernel paging request at 000f' gave a 449 character long sequence with very strange characters [0]. We should try to shorten it, imho. Not sure how to do that though. The man page for qrencode says you can have up to 4000 characters in a qrcode. However, I've seen readers have trouble with a 2048bit ascii armored PGP public key (3929 characters). I grabbed a random oops from oops.kernel.org, it weighed in at 1544 bytes, not too bad. I then did: $ echo https://oops.kernel.org/?qr=`cat oops.txt | gzip -9 | base64 -wrap=0` | wc -c 993 I did the same with another OOPS and it had 1953 characters. That's quite a big a big difference! :-) I created a QR image from the URL then, and it was 147x147, which is pretty small. It took me quite a long time to make my phone recognize it, but it worked nicely. Result of work is in this directory: http://levex.fedorapeople.org/kernel/qr/ nice! The benefit of a url is that any QR reader can automagically report an oops. While a specific app could parse the URL/oops locally if the user desires. it misses the point of having a QR code in the first place. The way I see it, having a QR decoder app installed that can do an offline decoding is a less greater effort than popping out a browser on the machine you're working on. I think you're selling the advantage of the QR code short. Automated reporting (via the url) is a _huge_ plus. The app you conceive of could still parse it in place if the user desires. My point for the URL isn't to use the internet/server to automate oops parsing for the user. Rather it's to make it easy to report oopses to developers. While still preserving the ability of your app to parse it for the user. Ah I see now. oops.kernel.org/?qr=QR would simply parse the base64'd+gzip'd oops message and then report it. If you mean the server behind oops.k.o would parse it, then yes. No special app should be required other than a QR code scanner for the usecase of reporting oopses to developers. Now I guess we need to think how to make it work without a framebuffer. I already suggested using the ASCII characters, but seeing the resolution of this QR code for example (147x147), made me realize that we can't shuffle that into a 80x25 textmode display. Any ideas how to fix that or should we just simply depend on a framebuffer being present? I think depending on the framebuffer being present (via kconfig) is sane. Folks running old systems know what they're in for, like missing shiny new features. ;-) thx, Jason. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Tue, Apr 1, 2014 at 5:20 PM, Jason Cooper ja...@lakedaemon.net wrote: On Sun, Mar 30, 2014 at 12:17:17PM +0200, Levente Kurusa wrote: Hi all, (sorry for the late reply, looks like this mail has ran away from my clients) same here. 2014-03-23 20:38 GMT+01:00 Jason Cooper ja...@lakedaemon.net: All, On Sat, Mar 22, 2014 at 08:20:01PM +0200, Teodora Băluţă wrote: On Sat, Mar 22, 2014 at 7:09 PM, Levente Kurusa le...@linux.com wrote: On 03/21/2014 02:28 PM, Jason Cooper wrote: ... 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. I still struggle to understand how could that be done. We can encode the QR code as ASCII. Okay, that's fine, however it is very long. Encoding 'Unable to handle kernel paging request at 000f' gave a 449 character long sequence with very strange characters [0]. We should try to shorten it, imho. Not sure how to do that though. The man page for qrencode says you can have up to 4000 characters in a qrcode. However, I've seen readers have trouble with a 2048bit ascii armored PGP public key (3929 characters). I grabbed a random oops from oops.kernel.org, it weighed in at 1544 bytes, not too bad. I then did: $ echo https://oops.kernel.org/?qr=`cat oops.txt | gzip -9 | base64 -wrap=0` | wc -c 993 I did the same with another OOPS and it had 1953 characters. That's quite a big a big difference! :-) I created a QR image from the URL then, and it was 147x147, which is pretty small. It took me quite a long time to make my phone recognize it, but it worked nicely. Result of work is in this directory: http://levex.fedorapeople.org/kernel/qr/ nice! The benefit of a url is that any QR reader can automagically report an oops. While a specific app could parse the URL/oops locally if the user desires. it misses the point of having a QR code in the first place. The way I see it, having a QR decoder app installed that can do an offline decoding is a less greater effort than popping out a browser on the machine you're working on. I think you're selling the advantage of the QR code short. Automated reporting (via the url) is a _huge_ plus. The app you conceive of could still parse it in place if the user desires. My point for the URL isn't to use the internet/server to automate oops parsing for the user. Rather it's to make it easy to report oopses to developers. While still preserving the ability of your app to parse it for the user. Ah I see now. oops.kernel.org/?qr=QR would simply parse the base64'd+gzip'd oops message and then report it. If you mean the server behind oops.k.o would parse it, then yes. No special app should be required other than a QR code scanner for the usecase of reporting oopses to developers. Now I guess we need to think how to make it work without a framebuffer. I already suggested using the ASCII characters, but seeing the resolution of this QR code for example (147x147), made me realize that we can't shuffle that into a 80x25 textmode display. Any ideas how to fix that or should we just simply depend on a framebuffer being present? I think depending on the framebuffer being present (via kconfig) is sane. Folks running old systems know what they're in for, like missing shiny new features. ;-) Ok, this may work. I agree that doing this with the help of the frame buffer is more natural. Thanks, -- Teodora thx, Jason. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
Hi all, (sorry for the late reply, looks like this mail has ran away from my clients) 2014-03-23 20:38 GMT+01:00 Jason Cooper : > All, > > On Sat, Mar 22, 2014 at 08:20:01PM +0200, Teodora Băluţă wrote: >> On Sat, Mar 22, 2014 at 7:09 PM, Levente Kurusa wrote: >> > On 03/21/2014 02:28 PM, Jason Cooper wrote: > ... >> >> 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. >> > >> > I still struggle to understand how could that be done. We can encode the >> > QR code as ASCII. Okay, that's fine, however it is very long. Encoding >> > 'Unable to handle kernel paging request at 000f' gave a 449 character >> > long sequence with very strange characters [0]. We should try to shorten >> > it, imho. Not sure how to do that though. > > The man page for qrencode says you can have up to 4000 characters in a > qrcode. However, I've seen readers have trouble with a 2048bit ascii > armored PGP public key (3929 characters). > > I grabbed a random oops from oops.kernel.org, it weighed in at 1544 > bytes, not too bad. I then did: > > $ echo "https://oops.kernel.org/?qr=`cat oops.txt | gzip -9 | base64 > -wrap=0`" | wc -c > 993 I did the same with another OOPS and it had 1953 characters. That's quite a big a big difference! :-) I created a QR image from the URL then, and it was 147x147, which is pretty small. It took me quite a long time to make my phone recognize it, but it worked nicely. Result of work is in this directory: http://levex.fedorapeople.org/kernel/qr/ > > The benefit of a url is that any QR reader can automagically report an > oops. While a specific app could parse the URL/oops locally if the > user desires. > >> it misses the point of having a QR code in the first place. The way I >> see it, having a QR decoder app installed that can do an offline >> decoding is a less greater effort than popping out a browser on the >> machine you're working on. > > I think you're selling the advantage of the QR code short. Automated > reporting (via the url) is a _huge_ plus. The app you conceive of could > still parse it in place if the user desires. > > My point for the URL isn't to use the internet/server to automate oops > parsing for the user. Rather it's to make it easy to report oopses to > developers. While still preserving the ability of your app to parse it > for the user. Ah I see now. oops.kernel.org/?qr= would simply parse the base64'd+gzip'd oops message and then report it. Now I guess we need to think how to make it work without a framebuffer. I already suggested using the ASCII characters, but seeing the resolution of this QR code for example (147x147), made me realize that we can't shuffle that into a 80x25 textmode display. Any ideas how to fix that or should we just simply depend on a framebuffer being present? -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
Hi all, (sorry for the late reply, looks like this mail has ran away from my clients) 2014-03-23 20:38 GMT+01:00 Jason Cooper ja...@lakedaemon.net: All, On Sat, Mar 22, 2014 at 08:20:01PM +0200, Teodora Băluţă wrote: On Sat, Mar 22, 2014 at 7:09 PM, Levente Kurusa le...@linux.com wrote: On 03/21/2014 02:28 PM, Jason Cooper wrote: ... 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. I still struggle to understand how could that be done. We can encode the QR code as ASCII. Okay, that's fine, however it is very long. Encoding 'Unable to handle kernel paging request at 000f' gave a 449 character long sequence with very strange characters [0]. We should try to shorten it, imho. Not sure how to do that though. The man page for qrencode says you can have up to 4000 characters in a qrcode. However, I've seen readers have trouble with a 2048bit ascii armored PGP public key (3929 characters). I grabbed a random oops from oops.kernel.org, it weighed in at 1544 bytes, not too bad. I then did: $ echo https://oops.kernel.org/?qr=`cat oops.txt | gzip -9 | base64 -wrap=0` | wc -c 993 I did the same with another OOPS and it had 1953 characters. That's quite a big a big difference! :-) I created a QR image from the URL then, and it was 147x147, which is pretty small. It took me quite a long time to make my phone recognize it, but it worked nicely. Result of work is in this directory: http://levex.fedorapeople.org/kernel/qr/ The benefit of a url is that any QR reader can automagically report an oops. While a specific app could parse the URL/oops locally if the user desires. it misses the point of having a QR code in the first place. The way I see it, having a QR decoder app installed that can do an offline decoding is a less greater effort than popping out a browser on the machine you're working on. I think you're selling the advantage of the QR code short. Automated reporting (via the url) is a _huge_ plus. The app you conceive of could still parse it in place if the user desires. My point for the URL isn't to use the internet/server to automate oops parsing for the user. Rather it's to make it easy to report oopses to developers. While still preserving the ability of your app to parse it for the user. Ah I see now. oops.kernel.org/?qr=QR would simply parse the base64'd+gzip'd oops message and then report it. Now I guess we need to think how to make it work without a framebuffer. I already suggested using the ASCII characters, but seeing the resolution of this QR code for example (147x147), made me realize that we can't shuffle that into a 80x25 textmode display. Any ideas how to fix that or should we just simply depend on a framebuffer being present? -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
All, On Sat, Mar 22, 2014 at 08:20:01PM +0200, Teodora Băluţă wrote: > On Sat, Mar 22, 2014 at 7:09 PM, Levente Kurusa wrote: > > On 03/21/2014 02:28 PM, Jason Cooper wrote: ... > >> 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. > > > > I still struggle to understand how could that be done. We can encode the > > QR code as ASCII. Okay, that's fine, however it is very long. Encoding > > 'Unable to handle kernel paging request at 000f' gave a 449 character > > long sequence with very strange characters [0]. We should try to shorten > > it, imho. Not sure how to do that though. The man page for qrencode says you can have up to 4000 characters in a qrcode. However, I've seen readers have trouble with a 2048bit ascii armored PGP public key (3929 characters). I grabbed a random oops from oops.kernel.org, it weighed in at 1544 bytes, not too bad. I then did: $ echo "https://oops.kernel.org/?qr=`cat oops.txt | gzip -9 | base64 -wrap=0`" | wc -c 993 The benefit of a url is that any QR reader can automagically report an oops. While a specific app could parse the URL/oops locally if the user desires. > it misses the point of having a QR code in the first place. The way I > see it, having a QR decoder app installed that can do an offline > decoding is a less greater effort than popping out a browser on the > machine you're working on. I think you're selling the advantage of the QR code short. Automated reporting (via the url) is a _huge_ plus. The app you conceive of could still parse it in place if the user desires. My point for the URL isn't to use the internet/server to automate oops parsing for the user. Rather it's to make it easy to report oopses to developers. While still preserving the ability of your app to parse it for the user. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
Hi,
On 03/22/2014 07:29 PM, Levente Kurusa wrote:
> Hi,
>
> On 03/22/2014 07:20 PM, Teodora Băluţă wrote:
>> On Sat, Mar 22, 2014 at 7:09 PM, Levente Kurusa wrote:
>>> Hi,
>>>
>>> On 03/21/2014 02:28 PM, Jason Cooper wrote:
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 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.
>>
>> [...]
>>
>> 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.
>>>
>>> Yea that is a better way. However, the current state of the code has
>>> several problems:
>>>
>>> * No good error handling (simply returns -1 on failure no matter what)
>>>I have began converting this to the ERR_PTR et al interface
>>>However, I have not yet done this fully due to the vast amount
>>>of work required to do so.
>>>This shouldn't be yet merged, but I shall send it as patches once
>>>it gets into the staging tree.
>>>
>>> * All memory allocations are GFP_ATOMIC for no reason.
>>>I have converted them to GFP_KERNEL since we can block safely.
>>>This could be merged to Teodora's branch. I can send her a pull
>>>request on GitHub if she wants so.
>>
>> Since we are talking about some kernel Oopses I thought that making
>> this GFP_ATOMIC ensures that we get memory allocation. I have
>> considered using GFP_KERNEL, but I am not very sure about that.
>> Probably somewhere deep inside I wanted to make it work even for
>> panics. :(
>
> Yea that makes sense, realized that just after I sent the mail.
> However, since this is in lib/ other parts might want to be
> able to use it and for them GFP_KERNEL makes more sense.
In order to make libqr usable in other parts of the kernel,
we need to heavily restructure libqr. It seems to use a style
that was inherited from OOP. Since we are in C, I don't like it.
I think that the allocations for the structs (e.g. QRinput) should
be done by the caller. That way we could remove most of the
allocations from libqr, and the rest may use GFP_KERNEL if they
still exist after that cleanup. Any objections?
>>>
>>> [...]
>>>
>>> * I had trouble getting QR output.
>>>Doing 'echo c > /proc/sysrq-trigger' triggered a crash,
>>>but it resulted in a recursive OOPS. This is a nullptr-deref
>>>and hence I think it may be related to the fact I was running
>>>it in textmode. :-)
>>>Or, it is due to the bugged error handling.
>>
>> The QR output is written to the frame buffer. That means you have to
>> get acces to a console. As I mentioned in the RFC, I am looking for an
>> alternative to using fb.h since that doesn't seem to work very well
>> atm.
Okay, I sent you a pull request that fixes a recursive OOPS when crashing
in textmode and no higher mode is available. Patch attached as well [0].
Also, have you check ASCII characters 219-223? Maybe they are usable?
Any ideas?
[0]:
%<-
From: Levente Kurusa
Subject: [PATCH] qr: print_oops: don't try to print if there is no framebuffer
If the kernel boots in textmode, we would hit a null pointer derefernce
in compute_w(). Prevent this by actually checking the value of info.
Signed-off-by: Levente Kurusa
---
kernel/print_oops.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/kernel/print_oops.c b/kernel/print_oops.c
index f43c059..f8909ba 100644
--- a/kernel/print_oops.c
+++ b/kernel/print_oops.c
@@ -126,6 +126,10 @@ void print_qr_err(void)
qr = QRcode_encodeData(compr_len, compr_qr_buffer, 0, QR_ECLEVEL_H);
info = registered_fb[0];
+ if (!info) {
+ printk(KERN_WARNING "Unable to get hand of a framebuffer!\n");
+ goto exit;
+ }
w = compute_w(info, qr->width);
rect.width = w;
@@ -167,6 +171,7 @@ void print_qr_err(void)
}
}
+exit:
QRcode_free(qr);
qr_compr_exit();
buf_pos = 0;
--
1.8.3.1
%<-
--
Regards,
Levente Kurusa
--
To unsubscribe from this list: send the line "unsubscribe
Re: [RFC] QR encoding for Oops messages
Hi,
On 03/22/2014 07:29 PM, Levente Kurusa wrote:
Hi,
On 03/22/2014 07:20 PM, Teodora Băluţă wrote:
On Sat, Mar 22, 2014 at 7:09 PM, Levente Kurusa le...@linux.com wrote:
Hi,
On 03/21/2014 02:28 PM, Jason Cooper wrote:
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 da...@redhat.com 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.
[...]
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.
Yea that is a better way. However, the current state of the code has
several problems:
* No good error handling (simply returns -1 on failure no matter what)
I have began converting this to the ERR_PTR et al interface
However, I have not yet done this fully due to the vast amount
of work required to do so.
This shouldn't be yet merged, but I shall send it as patches once
it gets into the staging tree.
* All memory allocations are GFP_ATOMIC for no reason.
I have converted them to GFP_KERNEL since we can block safely.
This could be merged to Teodora's branch. I can send her a pull
request on GitHub if she wants so.
Since we are talking about some kernel Oopses I thought that making
this GFP_ATOMIC ensures that we get memory allocation. I have
considered using GFP_KERNEL, but I am not very sure about that.
Probably somewhere deep inside I wanted to make it work even for
panics. :(
Yea that makes sense, realized that just after I sent the mail.
However, since this is in lib/ other parts might want to be
able to use it and for them GFP_KERNEL makes more sense.
In order to make libqr usable in other parts of the kernel,
we need to heavily restructure libqr. It seems to use a style
that was inherited from OOP. Since we are in C, I don't like it.
I think that the allocations for the structs (e.g. QRinput) should
be done by the caller. That way we could remove most of the
allocations from libqr, and the rest may use GFP_KERNEL if they
still exist after that cleanup. Any objections?
[...]
* I had trouble getting QR output.
Doing 'echo c /proc/sysrq-trigger' triggered a crash,
but it resulted in a recursive OOPS. This is a nullptr-deref
and hence I think it may be related to the fact I was running
it in textmode. :-)
Or, it is due to the bugged error handling.
The QR output is written to the frame buffer. That means you have to
get acces to a console. As I mentioned in the RFC, I am looking for an
alternative to using fb.h since that doesn't seem to work very well
atm.
Okay, I sent you a pull request that fixes a recursive OOPS when crashing
in textmode and no higher mode is available. Patch attached as well [0].
Also, have you check ASCII characters 219-223? Maybe they are usable?
Any ideas?
[0]:
%-
From: Levente Kurusa le...@linux.com
Subject: [PATCH] qr: print_oops: don't try to print if there is no framebuffer
If the kernel boots in textmode, we would hit a null pointer derefernce
in compute_w(). Prevent this by actually checking the value of info.
Signed-off-by: Levente Kurusa le...@linux.com
---
kernel/print_oops.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/kernel/print_oops.c b/kernel/print_oops.c
index f43c059..f8909ba 100644
--- a/kernel/print_oops.c
+++ b/kernel/print_oops.c
@@ -126,6 +126,10 @@ void print_qr_err(void)
qr = QRcode_encodeData(compr_len, compr_qr_buffer, 0, QR_ECLEVEL_H);
info = registered_fb[0];
+ if (!info) {
+ printk(KERN_WARNING Unable to get hand of a framebuffer!\n);
+ goto exit;
+ }
w = compute_w(info, qr-width);
rect.width = w;
@@ -167,6 +171,7 @@ void print_qr_err(void)
}
}
+exit:
QRcode_free(qr);
qr_compr_exit();
buf_pos = 0;
--
1.8.3.1
%-
--
Regards,
Levente Kurusa
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
All, On Sat, Mar 22, 2014 at 08:20:01PM +0200, Teodora Băluţă wrote: On Sat, Mar 22, 2014 at 7:09 PM, Levente Kurusa le...@linux.com wrote: On 03/21/2014 02:28 PM, Jason Cooper wrote: ... 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. I still struggle to understand how could that be done. We can encode the QR code as ASCII. Okay, that's fine, however it is very long. Encoding 'Unable to handle kernel paging request at 000f' gave a 449 character long sequence with very strange characters [0]. We should try to shorten it, imho. Not sure how to do that though. The man page for qrencode says you can have up to 4000 characters in a qrcode. However, I've seen readers have trouble with a 2048bit ascii armored PGP public key (3929 characters). I grabbed a random oops from oops.kernel.org, it weighed in at 1544 bytes, not too bad. I then did: $ echo https://oops.kernel.org/?qr=`cat oops.txt | gzip -9 | base64 -wrap=0` | wc -c 993 The benefit of a url is that any QR reader can automagically report an oops. While a specific app could parse the URL/oops locally if the user desires. it misses the point of having a QR code in the first place. The way I see it, having a QR decoder app installed that can do an offline decoding is a less greater effort than popping out a browser on the machine you're working on. I think you're selling the advantage of the QR code short. Automated reporting (via the url) is a _huge_ plus. The app you conceive of could still parse it in place if the user desires. My point for the URL isn't to use the internet/server to automate oops parsing for the user. Rather it's to make it easy to report oopses to developers. While still preserving the ability of your app to parse it for the user. thx, Jason. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
Hi, On 03/22/2014 07:20 PM, Teodora Băluţă wrote: > On Sat, Mar 22, 2014 at 7:09 PM, Levente Kurusa wrote: >> Hi, >> >> On 03/21/2014 02:28 PM, Jason Cooper wrote: >>> 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 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. > > [...] > > 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. >> >> Yea that is a better way. However, the current state of the code has >> several problems: >> >> * No good error handling (simply returns -1 on failure no matter what) >>I have began converting this to the ERR_PTR et al interface >>However, I have not yet done this fully due to the vast amount >>of work required to do so. >>This shouldn't be yet merged, but I shall send it as patches once >>it gets into the staging tree. >> >> * All memory allocations are GFP_ATOMIC for no reason. >>I have converted them to GFP_KERNEL since we can block safely. >>This could be merged to Teodora's branch. I can send her a pull >>request on GitHub if she wants so. > > Since we are talking about some kernel Oopses I thought that making > this GFP_ATOMIC ensures that we get memory allocation. I have > considered using GFP_KERNEL, but I am not very sure about that. > Probably somewhere deep inside I wanted to make it work even for > panics. :( Yea that makes sense, realized that just after I sent the mail. However, since this is in lib/ other parts might want to be able to use it and for them GFP_KERNEL makes more sense. > >> >> * Selecting QR_OOPS and QRLIB currently does not build due to >>undefined references to zlib_deflate* functions. >>This is due to QRLIB not selecting ZLIB_DEFLATE. >>Fixed this as well. Can be merged to Teodora if she wants. > > Hmm, that's odd. I thought I added a 'depends' in the menu. Please > make a pull request and I'll merge it immediately. Sent it, also attached the patch [0]. > >> >> * I had trouble getting QR output. >>Doing 'echo c > /proc/sysrq-trigger' triggered a crash, >>but it resulted in a recursive OOPS. This is a nullptr-deref >>and hence I think it may be related to the fact I was running >>it in textmode. :-) >>Or, it is due to the bugged error handling. > > The QR output is written to the frame buffer. That means you have to > get acces to a console. As I mentioned in the RFC, I am looking for an > alternative to using fb.h since that doesn't seem to work very well > atm. Yea this issue is significant. There are some ASCII codes which might work in textmode though. (219-223) Maybe it's worth a shot to try it out. > >> >>> >>> 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'll take a look. Thanks! > >>> >>> 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. >> >> I still struggle to understand how could that be done. We can encode the >> QR code as ASCII. Okay, that's fine, however it is very long. Encoding >> 'Unable to handle kernel paging request at 000f' gave a 449 character >> long sequence with very strange characters [0]. We should try to shorten >> it, imho. Not sure how to do that though. >> >> oops.kernel.org/?qr=CODE would look cool though. :-) > > I am not very sure that could be done. Accessing the QR code through a > link would mean you have to send it automatically to kernel.org (that > assumes a great deal of things like working Internet connection) and > it misses the point of having a QR code in the first place. The way I > see it, having a QR decoder app installed that can do an offline > decoding is a less greater effort than popping out a browser on the > machine you're working on. Yea I still think that mobiles are the way to go. However, why
Re: [RFC] QR encoding for Oops messages
On Sat, Mar 22, 2014 at 7:09 PM, Levente Kurusa wrote: > Hi, > > On 03/21/2014 02:28 PM, Jason Cooper wrote: >> 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 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. [...] 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. > > Yea that is a better way. However, the current state of the code has > several problems: > > * No good error handling (simply returns -1 on failure no matter what) >I have began converting this to the ERR_PTR et al interface >However, I have not yet done this fully due to the vast amount >of work required to do so. >This shouldn't be yet merged, but I shall send it as patches once >it gets into the staging tree. > > * All memory allocations are GFP_ATOMIC for no reason. >I have converted them to GFP_KERNEL since we can block safely. >This could be merged to Teodora's branch. I can send her a pull >request on GitHub if she wants so. Since we are talking about some kernel Oopses I thought that making this GFP_ATOMIC ensures that we get memory allocation. I have considered using GFP_KERNEL, but I am not very sure about that. Probably somewhere deep inside I wanted to make it work even for panics. :( > > * Selecting QR_OOPS and QRLIB currently does not build due to >undefined references to zlib_deflate* functions. >This is due to QRLIB not selecting ZLIB_DEFLATE. >Fixed this as well. Can be merged to Teodora if she wants. Hmm, that's odd. I thought I added a 'depends' in the menu. Please make a pull request and I'll merge it immediately. > > * I had trouble getting QR output. >Doing 'echo c > /proc/sysrq-trigger' triggered a crash, >but it resulted in a recursive OOPS. This is a nullptr-deref >and hence I think it may be related to the fact I was running >it in textmode. :-) >Or, it is due to the bugged error handling. The QR output is written to the frame buffer. That means you have to get acces to a console. As I mentioned in the RFC, I am looking for an alternative to using fb.h since that doesn't seem to work very well atm. > >> >> 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'll take a look. Thanks! >> >> 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. > > I still struggle to understand how could that be done. We can encode the > QR code as ASCII. Okay, that's fine, however it is very long. Encoding > 'Unable to handle kernel paging request at 000f' gave a 449 character > long sequence with very strange characters [0]. We should try to shorten > it, imho. Not sure how to do that though. > > oops.kernel.org/?qr=CODE would look cool though. :-) I am not very sure that could be done. Accessing the QR code through a link would mean you have to send it automatically to kernel.org (that assumes a great deal of things like working Internet connection) and it misses the point of having a QR code in the first place. The way I see it, having a QR decoder app installed that can do an offline decoding is a less greater effort than popping out a browser on the machine you're working on. And plus, as Levente said, encoding the QR code which does the Oops message encoding as text again (which would be large) would generate a very large link. -- Teodora >> >> Anyway, if you're interested, I'll be re-posting a patch for objdiff >> separately maybe today or this weekend. > > > [0]: http://paste.fedoraproject.org/87665/39550664/ > > > -- > Regards, > Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at
Re: [RFC] QR encoding for Oops messages
Hi, On 03/21/2014 02:28 PM, Jason Cooper wrote: > 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 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. >>> >>> [...] >>> >>> 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. Yea that is a better way. However, the current state of the code has several problems: * No good error handling (simply returns -1 on failure no matter what) I have began converting this to the ERR_PTR et al interface However, I have not yet done this fully due to the vast amount of work required to do so. This shouldn't be yet merged, but I shall send it as patches once it gets into the staging tree. * All memory allocations are GFP_ATOMIC for no reason. I have converted them to GFP_KERNEL since we can block safely. This could be merged to Teodora's branch. I can send her a pull request on GitHub if she wants so. * Selecting QR_OOPS and QRLIB currently does not build due to undefined references to zlib_deflate* functions. This is due to QRLIB not selecting ZLIB_DEFLATE. Fixed this as well. Can be merged to Teodora if she wants. * I had trouble getting QR output. Doing 'echo c > /proc/sysrq-trigger' triggered a crash, but it resulted in a recursive OOPS. This is a nullptr-deref and hence I think it may be related to the fact I was running it in textmode. :-) Or, it is due to the bugged error handling. > > 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. I still struggle to understand how could that be done. We can encode the QR code as ASCII. Okay, that's fine, however it is very long. Encoding 'Unable to handle kernel paging request at 000f' gave a 449 character long sequence with very strange characters [0]. We should try to shorten it, imho. Not sure how to do that though. oops.kernel.org/?qr=CODE would look cool though. :-) > > Anyway, if you're interested, I'll be re-posting a patch for objdiff > separately maybe today or this weekend. [0]: http://paste.fedoraproject.org/87665/39550664/ -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
Hi, On 03/21/2014 02:28 PM, Jason Cooper wrote: 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 da...@redhat.com 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. [...] 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. Yea that is a better way. However, the current state of the code has several problems: * No good error handling (simply returns -1 on failure no matter what) I have began converting this to the ERR_PTR et al interface However, I have not yet done this fully due to the vast amount of work required to do so. This shouldn't be yet merged, but I shall send it as patches once it gets into the staging tree. * All memory allocations are GFP_ATOMIC for no reason. I have converted them to GFP_KERNEL since we can block safely. This could be merged to Teodora's branch. I can send her a pull request on GitHub if she wants so. * Selecting QR_OOPS and QRLIB currently does not build due to undefined references to zlib_deflate* functions. This is due to QRLIB not selecting ZLIB_DEFLATE. Fixed this as well. Can be merged to Teodora if she wants. * I had trouble getting QR output. Doing 'echo c /proc/sysrq-trigger' triggered a crash, but it resulted in a recursive OOPS. This is a nullptr-deref and hence I think it may be related to the fact I was running it in textmode. :-) Or, it is due to the bugged error handling. 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. I still struggle to understand how could that be done. We can encode the QR code as ASCII. Okay, that's fine, however it is very long. Encoding 'Unable to handle kernel paging request at 000f' gave a 449 character long sequence with very strange characters [0]. We should try to shorten it, imho. Not sure how to do that though. oops.kernel.org/?qr=CODE would look cool though. :-) Anyway, if you're interested, I'll be re-posting a patch for objdiff separately maybe today or this weekend. [0]: http://paste.fedoraproject.org/87665/39550664/ -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Sat, Mar 22, 2014 at 7:09 PM, Levente Kurusa le...@linux.com wrote: Hi, On 03/21/2014 02:28 PM, Jason Cooper wrote: 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 da...@redhat.com 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. [...] 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. Yea that is a better way. However, the current state of the code has several problems: * No good error handling (simply returns -1 on failure no matter what) I have began converting this to the ERR_PTR et al interface However, I have not yet done this fully due to the vast amount of work required to do so. This shouldn't be yet merged, but I shall send it as patches once it gets into the staging tree. * All memory allocations are GFP_ATOMIC for no reason. I have converted them to GFP_KERNEL since we can block safely. This could be merged to Teodora's branch. I can send her a pull request on GitHub if she wants so. Since we are talking about some kernel Oopses I thought that making this GFP_ATOMIC ensures that we get memory allocation. I have considered using GFP_KERNEL, but I am not very sure about that. Probably somewhere deep inside I wanted to make it work even for panics. :( * Selecting QR_OOPS and QRLIB currently does not build due to undefined references to zlib_deflate* functions. This is due to QRLIB not selecting ZLIB_DEFLATE. Fixed this as well. Can be merged to Teodora if she wants. Hmm, that's odd. I thought I added a 'depends' in the menu. Please make a pull request and I'll merge it immediately. * I had trouble getting QR output. Doing 'echo c /proc/sysrq-trigger' triggered a crash, but it resulted in a recursive OOPS. This is a nullptr-deref and hence I think it may be related to the fact I was running it in textmode. :-) Or, it is due to the bugged error handling. The QR output is written to the frame buffer. That means you have to get acces to a console. As I mentioned in the RFC, I am looking for an alternative to using fb.h since that doesn't seem to work very well atm. 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'll take a look. Thanks! 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. I still struggle to understand how could that be done. We can encode the QR code as ASCII. Okay, that's fine, however it is very long. Encoding 'Unable to handle kernel paging request at 000f' gave a 449 character long sequence with very strange characters [0]. We should try to shorten it, imho. Not sure how to do that though. oops.kernel.org/?qr=CODE would look cool though. :-) I am not very sure that could be done. Accessing the QR code through a link would mean you have to send it automatically to kernel.org (that assumes a great deal of things like working Internet connection) and it misses the point of having a QR code in the first place. The way I see it, having a QR decoder app installed that can do an offline decoding is a less greater effort than popping out a browser on the machine you're working on. And plus, as Levente said, encoding the QR code which does the Oops message encoding as text again (which would be large) would generate a very large link. -- Teodora Anyway, if you're interested, I'll be re-posting a patch for objdiff separately maybe today or this weekend. [0]: http://paste.fedoraproject.org/87665/39550664/ -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
Hi, On 03/22/2014 07:20 PM, Teodora Băluţă wrote: On Sat, Mar 22, 2014 at 7:09 PM, Levente Kurusa le...@linux.com wrote: Hi, On 03/21/2014 02:28 PM, Jason Cooper wrote: 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 da...@redhat.com 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. [...] 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. Yea that is a better way. However, the current state of the code has several problems: * No good error handling (simply returns -1 on failure no matter what) I have began converting this to the ERR_PTR et al interface However, I have not yet done this fully due to the vast amount of work required to do so. This shouldn't be yet merged, but I shall send it as patches once it gets into the staging tree. * All memory allocations are GFP_ATOMIC for no reason. I have converted them to GFP_KERNEL since we can block safely. This could be merged to Teodora's branch. I can send her a pull request on GitHub if she wants so. Since we are talking about some kernel Oopses I thought that making this GFP_ATOMIC ensures that we get memory allocation. I have considered using GFP_KERNEL, but I am not very sure about that. Probably somewhere deep inside I wanted to make it work even for panics. :( Yea that makes sense, realized that just after I sent the mail. However, since this is in lib/ other parts might want to be able to use it and for them GFP_KERNEL makes more sense. * Selecting QR_OOPS and QRLIB currently does not build due to undefined references to zlib_deflate* functions. This is due to QRLIB not selecting ZLIB_DEFLATE. Fixed this as well. Can be merged to Teodora if she wants. Hmm, that's odd. I thought I added a 'depends' in the menu. Please make a pull request and I'll merge it immediately. Sent it, also attached the patch [0]. * I had trouble getting QR output. Doing 'echo c /proc/sysrq-trigger' triggered a crash, but it resulted in a recursive OOPS. This is a nullptr-deref and hence I think it may be related to the fact I was running it in textmode. :-) Or, it is due to the bugged error handling. The QR output is written to the frame buffer. That means you have to get acces to a console. As I mentioned in the RFC, I am looking for an alternative to using fb.h since that doesn't seem to work very well atm. Yea this issue is significant. There are some ASCII codes which might work in textmode though. (219-223) Maybe it's worth a shot to try it out. 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'll take a look. Thanks! 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. I still struggle to understand how could that be done. We can encode the QR code as ASCII. Okay, that's fine, however it is very long. Encoding 'Unable to handle kernel paging request at 000f' gave a 449 character long sequence with very strange characters [0]. We should try to shorten it, imho. Not sure how to do that though. oops.kernel.org/?qr=CODE would look cool though. :-) I am not very sure that could be done. Accessing the QR code through a link would mean you have to send it automatically to kernel.org (that assumes a great deal of things like working Internet connection) and it misses the point of having a QR code in the first place. The way I see it, having a QR decoder app installed that can do an offline decoding is a less greater effort than popping out a browser on the machine you're working on. Yea I still think that mobiles are the way to go. However, why would we need internet connection? We could just output a formatted link like oops.kernel.org/?qr=%s where %s will take the ASCII QR Code. Or something among those lines. And plus, as Levente said, encoding the QR code
Re: [RFC] QR encoding for Oops messages
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 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.ja...@lakedaemon.net [2] https://lkml.kernel.org/r/cover.1394570067.git.ja...@lakedaemon.net [3] https://lkml.kernel.org/r/20140312165501.gc7...@titan.lakedaemon.net -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
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 da...@redhat.com 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.ja...@lakedaemon.net [2] https://lkml.kernel.org/r/cover.1394570067.git.ja...@lakedaemon.net [3] https://lkml.kernel.org/r/20140312165501.gc7...@titan.lakedaemon.net -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
Hi, 2014-03-19 21:50 GMT+01:00 Teodora Băluţă : > On Wed, Mar 19, 2014 at 10:28 PM, Levente Kurusa wrote: >> Hi, >> >> 2014-03-19 21:18 GMT+01:00 Dave Jones : >>> 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(-) >> >> This idea is certainly great. >> >> However, there are quite a few problems with the code in terms of code style >> and >> other terms as well. I am not sure how could we help you make this code >> appliable, but it would be great if you put up a branch somewhere. This way >> I could send you a few commits that do some fixups. > > Wow, that'd be great! I have set up my clone of the kernel source up > on gitlab [0] and github [1]. I will update the remote branch asap (I > made some coding style fixups that aren't present on github/gitlab > right now, only in a remote branch). Is this ok? Yea, that's fine. Push your changes and send me a ping once you are done. I will most likely send you a pull request on github though. > >> >>> >>> That's a ton of code we're adding into one of the most fragile parts of the >>> kernel. >> >> Indeed, this should get split up. >> >>> >>> 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. >>> >>> How much of this could we drop ? >> >> A lot, most likely. > > Indeed. > >> >> Also, I wonder if we could do the same for panic()? >> I hate it when I receive a panic and I have no idea what's the cause >> since my display is filled up with the stack trace. > > Most likely panic is harder to do for reasons discussed in this thread here > [2]. > Yes I see. > > [0] https://gitlab.com/teobaluta/opw > [1] https://github.com/teobaluta/qr-linux-kernel > [2] https://lwn.net/Articles/503677/ > > Thanks, > Teodora >> >> -- >> Regards, >> Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Wed, Mar 19, 2014 at 10:50 PM, Teodora Băluţă wrote: > On Wed, Mar 19, 2014 at 10:28 PM, Levente Kurusa wrote: >> Hi, >> >> 2014-03-19 21:18 GMT+01:00 Dave Jones : >>> 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(-) >> >> This idea is certainly great. >> >> However, there are quite a few problems with the code in terms of code style >> and >> other terms as well. I am not sure how could we help you make this code >> appliable, but it would be great if you put up a branch somewhere. This way >> I could send you a few commits that do some fixups. > > Wow, that'd be great! I have set up my clone of the kernel source up > on gitlab [0] and github [1]. I will update the remote branch asap (I > made some coding style fixups that aren't present on github/gitlab > right now, only in a remote branch). Is this ok? Of course, I meant local branch. Sorry for spamming. > >> >>> >>> That's a ton of code we're adding into one of the most fragile parts of the >>> kernel. >> >> Indeed, this should get split up. >> >>> >>> 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. >>> >>> How much of this could we drop ? >> >> A lot, most likely. > > Indeed. > >> >> Also, I wonder if we could do the same for panic()? >> I hate it when I receive a panic and I have no idea what's the cause >> since my display is filled up with the stack trace. > > Most likely panic is harder to do for reasons discussed in this thread here > [2]. > > > [0] https://gitlab.com/teobaluta/opw > [1] https://github.com/teobaluta/qr-linux-kernel > [2] https://lwn.net/Articles/503677/ > > Thanks, > Teodora >> >> -- >> Regards, >> Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Wed, Mar 19, 2014 at 10:28 PM, Levente Kurusa wrote: > Hi, > > 2014-03-19 21:18 GMT+01:00 Dave Jones : >> 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(-) > > This idea is certainly great. > > However, there are quite a few problems with the code in terms of code style > and > other terms as well. I am not sure how could we help you make this code > appliable, but it would be great if you put up a branch somewhere. This way > I could send you a few commits that do some fixups. Wow, that'd be great! I have set up my clone of the kernel source up on gitlab [0] and github [1]. I will update the remote branch asap (I made some coding style fixups that aren't present on github/gitlab right now, only in a remote branch). Is this ok? > >> >> That's a ton of code we're adding into one of the most fragile parts of the >> kernel. > > Indeed, this should get split up. > >> >> 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. >> >> How much of this could we drop ? > > A lot, most likely. Indeed. > > Also, I wonder if we could do the same for panic()? > I hate it when I receive a panic and I have no idea what's the cause > since my display is filled up with the stack trace. Most likely panic is harder to do for reasons discussed in this thread here [2]. [0] https://gitlab.com/teobaluta/opw [1] https://github.com/teobaluta/qr-linux-kernel [2] https://lwn.net/Articles/503677/ Thanks, Teodora > > -- > Regards, > Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Wed, Mar 19, 2014 at 10:18 PM, Dave Jones 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. > > How much of this could we drop ? There are two things to do: remove all the other modes except binary (kanji, numerical, etc.) and use the Reed Solomon encode/decode in the lib/reed_solomon/ folder as not to have redundacy. So to say, quite a lot. Thanks, -- Teodora > > Dave > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
Hi, 2014-03-19 21:18 GMT+01:00 Dave Jones : > 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(-) This idea is certainly great. However, there are quite a few problems with the code in terms of code style and other terms as well. I am not sure how could we help you make this code appliable, but it would be great if you put up a branch somewhere. This way I could send you a few commits that do some fixups. > > That's a ton of code we're adding into one of the most fragile parts of the > kernel. Indeed, this should get split up. > > 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. > > How much of this could we drop ? A lot, most likely. Also, I wonder if we could do the same for panic()? I hate it when I receive a panic and I have no idea what's the cause since my display is filled up with the stack trace. -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
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. How much of this could we drop ? Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Wed, Mar 19, 2014 at 8:03 PM, Borislav Petkov 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. > -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Tue, Mar 18, 2014 at 11:49 PM, Matthew Garrett wrote: > On Mon, Mar 17, 2014 at 02:59:47PM -0700, Teodora Baluta wrote: > >> 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. > > When I was thinking about doing this a while ago, my plan was to simply > encode the oops as a URL - that way existing QR reader software would > work and there's no need to write a specialised application. I also > registered the domain kbu.gs to provide the service. Obviously I never > got around to actually writing the code, so this is great! That would have worked as well, I guess. I really hope to get this into shape for it to be accepted. Thanks. -- Teodora > > -- > Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
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. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
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. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Tue, Mar 18, 2014 at 11:49 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Mon, Mar 17, 2014 at 02:59:47PM -0700, Teodora Baluta wrote: 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. When I was thinking about doing this a while ago, my plan was to simply encode the oops as a URL - that way existing QR reader software would work and there's no need to write a specialised application. I also registered the domain kbu.gs to provide the service. Obviously I never got around to actually writing the code, so this is great! That would have worked as well, I guess. I really hope to get this into shape for it to be accepted. Thanks. -- Teodora -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
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. How much of this could we drop ? Dave -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
Hi, 2014-03-19 21:18 GMT+01:00 Dave Jones da...@redhat.com: 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(-) This idea is certainly great. However, there are quite a few problems with the code in terms of code style and other terms as well. I am not sure how could we help you make this code appliable, but it would be great if you put up a branch somewhere. This way I could send you a few commits that do some fixups. That's a ton of code we're adding into one of the most fragile parts of the kernel. Indeed, this should get split up. 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. How much of this could we drop ? A lot, most likely. Also, I wonder if we could do the same for panic()? I hate it when I receive a panic and I have no idea what's the cause since my display is filled up with the stack trace. -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Wed, Mar 19, 2014 at 8:03 PM, Borislav Petkov b...@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. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Wed, Mar 19, 2014 at 10:18 PM, Dave Jones da...@redhat.com 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. How much of this could we drop ? There are two things to do: remove all the other modes except binary (kanji, numerical, etc.) and use the Reed Solomon encode/decode in the lib/reed_solomon/ folder as not to have redundacy. So to say, quite a lot. Thanks, -- Teodora Dave -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Wed, Mar 19, 2014 at 10:28 PM, Levente Kurusa le...@linux.com wrote: Hi, 2014-03-19 21:18 GMT+01:00 Dave Jones da...@redhat.com: 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(-) This idea is certainly great. However, there are quite a few problems with the code in terms of code style and other terms as well. I am not sure how could we help you make this code appliable, but it would be great if you put up a branch somewhere. This way I could send you a few commits that do some fixups. Wow, that'd be great! I have set up my clone of the kernel source up on gitlab [0] and github [1]. I will update the remote branch asap (I made some coding style fixups that aren't present on github/gitlab right now, only in a remote branch). Is this ok? That's a ton of code we're adding into one of the most fragile parts of the kernel. Indeed, this should get split up. 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. How much of this could we drop ? A lot, most likely. Indeed. Also, I wonder if we could do the same for panic()? I hate it when I receive a panic and I have no idea what's the cause since my display is filled up with the stack trace. Most likely panic is harder to do for reasons discussed in this thread here [2]. [0] https://gitlab.com/teobaluta/opw [1] https://github.com/teobaluta/qr-linux-kernel [2] https://lwn.net/Articles/503677/ Thanks, Teodora -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Wed, Mar 19, 2014 at 10:50 PM, Teodora Băluţă teobal...@gmail.com wrote: On Wed, Mar 19, 2014 at 10:28 PM, Levente Kurusa le...@linux.com wrote: Hi, 2014-03-19 21:18 GMT+01:00 Dave Jones da...@redhat.com: 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(-) This idea is certainly great. However, there are quite a few problems with the code in terms of code style and other terms as well. I am not sure how could we help you make this code appliable, but it would be great if you put up a branch somewhere. This way I could send you a few commits that do some fixups. Wow, that'd be great! I have set up my clone of the kernel source up on gitlab [0] and github [1]. I will update the remote branch asap (I made some coding style fixups that aren't present on github/gitlab right now, only in a remote branch). Is this ok? Of course, I meant local branch. Sorry for spamming. That's a ton of code we're adding into one of the most fragile parts of the kernel. Indeed, this should get split up. 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. How much of this could we drop ? A lot, most likely. Indeed. Also, I wonder if we could do the same for panic()? I hate it when I receive a panic and I have no idea what's the cause since my display is filled up with the stack trace. Most likely panic is harder to do for reasons discussed in this thread here [2]. [0] https://gitlab.com/teobaluta/opw [1] https://github.com/teobaluta/qr-linux-kernel [2] https://lwn.net/Articles/503677/ Thanks, Teodora -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
Hi, 2014-03-19 21:50 GMT+01:00 Teodora Băluţă teobal...@gmail.com: On Wed, Mar 19, 2014 at 10:28 PM, Levente Kurusa le...@linux.com wrote: Hi, 2014-03-19 21:18 GMT+01:00 Dave Jones da...@redhat.com: 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(-) This idea is certainly great. However, there are quite a few problems with the code in terms of code style and other terms as well. I am not sure how could we help you make this code appliable, but it would be great if you put up a branch somewhere. This way I could send you a few commits that do some fixups. Wow, that'd be great! I have set up my clone of the kernel source up on gitlab [0] and github [1]. I will update the remote branch asap (I made some coding style fixups that aren't present on github/gitlab right now, only in a remote branch). Is this ok? Yea, that's fine. Push your changes and send me a ping once you are done. I will most likely send you a pull request on github though. That's a ton of code we're adding into one of the most fragile parts of the kernel. Indeed, this should get split up. 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. How much of this could we drop ? A lot, most likely. Indeed. Also, I wonder if we could do the same for panic()? I hate it when I receive a panic and I have no idea what's the cause since my display is filled up with the stack trace. Most likely panic is harder to do for reasons discussed in this thread here [2]. Yes I see. [0] https://gitlab.com/teobaluta/opw [1] https://github.com/teobaluta/qr-linux-kernel [2] https://lwn.net/Articles/503677/ Thanks, Teodora -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Mon, Mar 17, 2014 at 02:59:47PM -0700, Teodora Baluta wrote: > 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. When I was thinking about doing this a while ago, my plan was to simply encode the oops as a URL - that way existing QR reader software would work and there's no need to write a specialised application. I also registered the domain kbu.gs to provide the service. Obviously I never got around to actually writing the code, so this is great! -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] QR encoding for Oops messages
On Mon, Mar 17, 2014 at 02:59:47PM -0700, Teodora Baluta wrote: 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. When I was thinking about doing this a while ago, my plan was to simply encode the oops as a URL - that way existing QR reader software would work and there's no need to write a specialised application. I also registered the domain kbu.gs to provide the service. Obviously I never got around to actually writing the code, so this is great! -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
