Messages in this thread | | | Date | Sun, 2 Jul 2000 01:03:00 -0700 (PDT) | From | Chris Lattner <> | Subject | Re: [PATCH #2] console lock grabbed too early in printk... |
| |
> I think you are missing the point. printk can be called even before > kmalloc is usable and you cannot tell if kmalloc can be called yet. > Yes, it is unlikely but crashing during debugging just complicates > things. Far better to just count and report dropped messages and never > call any other kernel functions from printk. It also keeps a critical > kernel function nice and simple.
Wait, back up, let me get this straight. There are two situations here:
1. Recursive printk occurs before kmalloc is initialized: You claim that a panic is WORSE for debugging that an undetected deadlock is? How does that assist with debugging??? 2. Recursive printk occurs after kmalloc is initialized: You claim that merely counting the failed messages is better than doing _THE_RIGHT_THING_ is every case except OOM (which would be treated quite similarly to what you are describing....
Please clear up these issues... because I believe I understand what you are implying, just doing understand your reasonings...
-Chris
btw, if nothing else, why not just print out the format str on OOM? That way you don't even need a buffer...
- 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/
| |