On Mon, 3 Jul 2000, Jeff Garzik wrote:
> I'm trying to whittle "make more robust" into something more concrete.
> Currently there is a namespace collision with 'buf' in printk.c (your
> patch #4), but I just don't see anything more than that. Since 'buf' is
> protected by console_lock currently, things seem to be otherwise ok.
> Recursive printk? Lost messages? Your patch #4 seems like just a bunch
> of extra code for rare if not impossible cases.
Although I explained this in depth before, I will do a quick recap on my
motivation:
1. It is "theoretically impossible" to get recursive printk behavior from
a stock linux kernel.
2. People need to debug new work, and some old work, and other stuff just
to see how things work.
3. printk is a quick and dirty method of debugging, which is widely used.
4. When people use printk, they are most often throwing them in all over
the place to try to figure out what the heck is going on.
5. As such, a kernel developer may not invest as much thought into printk
placement as, say, a new buffer cache design.
6. Poor judgement and placement of printk's can lead to recursive
printk's.
7. The recursive printk problem is easily solved, cheaply repaired, and a
pain in the butt to diagnose.
This is all based on the idea that people use printk for debugging, which
is an assumption based on my development habits. If printk is
"officially" viewed as "not for debugging" then it doesn't matter how
forgiving it is, and my argument is fruitless.
If, on the other hand, people DO intend to use printk for debugging,
everyone wins by making it more forgiving and tolerant of misuse and
abuse.
To solve this, I see two main strategies that are usable:
1. Count printk's that cannot be used due to recursive entries. On the
next successful printk, indicate that some printk's were lost.
2. kmalloc(GFP_ATOMIC) a temporary buffer, and try our damnest to get the
message through to the user/kernel developer.
Personally, I don't care which one is used, I just don't want to get
burned again in the future.
-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:13 EST