Messages in this thread |  | | Subject | Re: Cosmetic JFFS patch. | Date | Fri, 29 Jun 2001 15:47:30 -0400 | From | Hacksaw <> |
| |
>No 'debug=' could then simply cause the kernel to kprint any info from >drivers/modules that failed to load, else keep schtum.
My idea is that the driver announces itself, and then what it has found/initialized, in the minimum number of screen lines possible. I'd want that to be the default, because it gives you a decent idea of where it was if it failed.
I am envisioning an algorithm like this:
1. Printk name and version 2. initialize self 3. Hunt for devices, printk when you find one 4. Initialize this device 5. Go back to 3 until you don't detect any more devices 6. Do whatever final thing needs doing
Note that I only advocate the two printk's mentioned explicitly. I think this provides just enough of a clue to give one an idea of what might have gone wrong, so you might be able to make a quick fix even before needing to enter a "tell me everything you are doing" mode for debugging. More might be nice, but balance is good.
I agree with some folks that this is way too much from some drivers. The giant per CPU tables are an example. That's a useful thing if you are a kernel developer, or are trying to debug something weird, but it too much information for someone like me, who knows the code works most of the time. If I see an error, I'm going to replace the CPU, not write new code.
On the other hand, I do like the v for version, etc thing, but I think I would have it like this:
v for version i for initiation progress (devices and options) d for debugging (or tell me every major step you take) q for quiet (Just the kernel version and the word "Loading" and a spinner of some sort) s for "shut up shuttin' up!" (Nothing, or maybe some custom module for the embedded installations)
Obviously, the last two are exclusive with the first three. I'd make it so including them after the other cancels them, so you could add something temporarily without losing your default.
I would default to "vi", no pun intended.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |