Re: Cosmetic JFFS patch.

[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.