Messages in this thread | | | Date | Mon, 08 Dec 2008 10:42:08 +0900 | From | Tejun Heo <> | Subject | Re: [RFC] Recursive printk |
| |
Hello,
Nick Andrew wrote: >> Tejun had a thing a while ago which was kinda intended to solve the >> same problem. iirc his approach added a lot more code (bad), but >> didn't go and add strange new semantics to printk. > > I'm not trying to solve a huge problem (e.g. as Jason Baron's dynamic > debug does), just a small problem. Why do tasks have to choose > between double-buffering their messages and making multiple calls > to printk?
Yeah, my patch happened to solve about the same problem (and mprintk proper was ~370 lines, so it wasn't too bad). Mine went the way of assembling messages piece-by-piece and most of the complexities came from buffer management and fallback (e.g. even if kmalloc fails to allocate messages, messages still get printed out, albeit a bit uglier).
>> IOW, for this to be halfway as useful as you expect, we need a >> look-out-for-local-printk-hacks maintainer. > > If my patch makes it in, it will be followed by fixes to all > those local hacks. We might discover some common element so they > can be made non-local. Once a better way to interface to printk > becomes prevalent, it will probably be reused. And if it's not, > then it affects only the one subsystem.
No matter which mechanism, I'd love to have something to solve this in kernel. I face this problem quite often and each and every time I have to come up with some custom hack to work around it.
FWIW, this was the last take of the mprintk patchset.
http://thread.gmane.org/gmane.linux.ide/28415
Thanks.
-- tejun
| |