>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/
This archive was generated by hypermail 2b29 : Sat Jun 30 2001 - 21:00:23 EST