x86_emu_debug.diff: Change DEBUG for the emulator to DEBUG_EMU to avoid conflicts with DEBUG for log levels.
loglevel.diff: Remove BIOS_EMERG, BIOS_ALERT, BIOS_CRIT, BIOS_NOTICE, BIOS_NEVER I didn't change their numerical values. They were rarely used. BIOS_EMERG, BIOS_ALERT, BIOS_CRIT -> BIOS_ERR BIOS_NOTICE -> BIOS_INFO BIOS_NEVER -> BIOS_SPEW+1
loglevel2.diff: BIOS_ERR -> ERROR BIOS_WARNING -> WARNING BIOS_INFO -> INFO BIOS_DEBUG -> DEBUG BIOS_SPEW -> SPEW For 80 character line aficionados, this puts most of the lines back, since printk_debug(...) is about the same length as printk(DEBUG, ...)
I didn't change llshell in any of these patches. It would be easy to add.
Abuild tested. Signed-off-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
On 4/2/10 7:55 PM, Myles Watson wrote:
loglevel.diff: Remove BIOS_EMERG, BIOS_ALERT, BIOS_CRIT, BIOS_NOTICE, BIOS_NEVER
I am not convinced that's a good idea. But let's hear what other people say...
I didn't change their numerical values. They were rarely used. BIOS_EMERG, BIOS_ALERT, BIOS_CRIT -> BIOS_ERR BIOS_NOTICE -> BIOS_INFO
I don't think we want to just remove log levels like that. Let's rather fix the messages and choose the right log levels for them.
BIOS_NEVER -> BIOS_SPEW+1
The whole intent was to make clear to the reader that this is something that's never seen. ;-) That doesn't become clear from BIOS_SPEW+1 in my opinion.
loglevel2.diff: BIOS_ERR -> ERROR BIOS_WARNING -> WARNING BIOS_INFO -> INFO BIOS_DEBUG -> DEBUG BIOS_SPEW -> SPEW For 80 character line aficionados, this puts most of the lines back, since printk_debug(...) is about the same length as printk(DEBUG, ...)
I kind of like the fact that they are prefixed, while I see the point that BIOS_ is a bad prefix. What about LOG_? Because, that's what it is, log levels. I like the idea of not abbreviating ERROR to ERR as the only exception to the rule.
Stefan
On Fri, Apr 2, 2010 at 4:19 PM, Stefan Reinauer stepan@coresystems.dewrote:
On 4/2/10 7:55 PM, Myles Watson wrote:
loglevel.diff: Remove BIOS_EMERG, BIOS_ALERT, BIOS_CRIT, BIOS_NOTICE, BIOS_NEVER
I am not convinced that's a good idea. But let's hear what other people say...
They were used so infrequently that they were just noise to me.
I didn't change their numerical values. They were rarely used. BIOS_EMERG, BIOS_ALERT, BIOS_CRIT -> BIOS_ERR BIOS_NOTICE -> BIOS_INFO
I don't think we want to just remove log levels like that. Let's rather fix the messages and choose the right log levels for them.
I think it preserves the meaning. Emergency, alert, and critical all seem like errors. The difference between notice and info seems like splitting hairs.
BIOS_NEVER -> BIOS_SPEW+1
The whole intent was to make clear to the reader that this is something that's never seen. ;-) That doesn't become clear from BIOS_SPEW+1 in my opinion.
NEVER was only used once or twice in the code. If it's something that will be used more often, then I can see your point. Why don't we just comment out messages that will never be seen?
loglevel2.diff: BIOS_ERR -> ERROR BIOS_WARNING -> WARNING BIOS_INFO -> INFO BIOS_DEBUG -> DEBUG BIOS_SPEW -> SPEW For 80 character line aficionados, this puts most of the lines back, since printk_debug(...) is about the same length as printk(DEBUG, ...)
I kind of like the fact that they are prefixed, while I see the point that BIOS_ is a bad prefix. What about LOG_? Because, that's what it is, log levels.
I think printk works well for the prefix, and I like brevity when it doesn't interfere with the meaning. I think we talked about other prefixes some time in the past and couldn't get agreement.
I like the idea of not abbreviating ERROR to ERR as the only exception to the rule.
Good. I've mis-typed that a lot of times. I like uniformity.
Thanks, Myles
BIOS_NEVER -> BIOS_SPEW+1
The whole intent was to make clear to the reader that this is something that's never seen. ;-) That doesn't become clear from BIOS_SPEW+1 in my opinion.
NEVER was only used once or twice in the code. If it's something that will be used more often, then I can see your point. Why don't we just comment out messages that will never be seen?
I just looked again, and it was only used once. It makes sense where it was used, but I don't think it makes sense to use it other places, and I think naming it with the same prefix and including it in the same list makes that likely in the future.
I think a comment explaining BIOS_SPEW+1 would work just as well, or this: BIOS_NEVER -> CONFIG_MAXIMUM_CONSOLE_LOGLEVEL+1
Thanks, Myles
On 04/02/2010 06:19 PM, Stefan Reinauer wrote:
On 4/2/10 7:55 PM, Myles Watson wrote:
loglevel.diff: Remove BIOS_EMERG, BIOS_ALERT, BIOS_CRIT, BIOS_NOTICE, BIOS_NEVER
I am not convinced that's a good idea. But let's hear what other people say...
I didn't change their numerical values. They were rarely used. BIOS_EMERG, BIOS_ALERT, BIOS_CRIT -> BIOS_ERR BIOS_NOTICE -> BIOS_INFO
I don't think we want to just remove log levels like that. Let's rather fix the messages and choose the right log levels for them.
BIOS_NEVER -> BIOS_SPEW+1
The whole intent was to make clear to the reader that this is something that's never seen. ;-) That doesn't become clear from BIOS_SPEW+1 in my opinion.
loglevel2.diff: BIOS_ERR -> ERROR BIOS_WARNING -> WARNING BIOS_INFO -> INFO BIOS_DEBUG -> DEBUG BIOS_SPEW -> SPEW For 80 character line aficionados, this puts most of the lines back, since printk_debug(...) is about the same length as printk(DEBUG, ...)
I kind of like the fact that they are prefixed, while I see the point that BIOS_ is a bad prefix. What about LOG_? Because, that's what it is, log levels. I like the idea of not abbreviating ERROR to ERR as the only exception to the rule.
Stefan
Yes I agree Stefan, lets get that _BIOS_ out of coreboot.
-
Joseph Smith -
Myles Watson -
Stefan Reinauer