Okay, here's two more tries at making printk a little more robust in the
face of people being silly like me. :) Patch #3 has these benefits:
1. The console_lock is held for a shorter period of time: ie other
unrelated console stuff can be happening while vsprintf is
"rasterizing" the string.
2. Recursive printk's won't deadlock the code
3. Recursive printk's count the number of missed messages and print that
number out when possible.
4. No extra kernel calls are made from within printk (except atomic
operations, big deal... :)
Personally, I think reason #1 is justification enough for this patch. If
people don't like this patch, then I offer up patch #4:
1. "buf" is moved into printk as a static member, so that people can see
that console_lock is protecting it. This also means that when you look at
a "buf" in the file, you can tell whether it's the global one or a
parameter without looking too hard.
Let me know if either of these are reasonable... :)
-Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:11 EST