Messages in this thread | | | Date | Mon, 3 Jul 2000 17:04:03 -0700 (PDT) | From | Chris Lattner <> | Subject | Re: [PATCH #2] console lock grabbed too early in printk... |
| |
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/
| |