On 20.06.2009 02:50, ron minnich wrote:
reminder. do_printk is (or should be) used ONLY in the CAR code.
AFAICS all printk_* calls are #defined to do_printk.
It does not use variables that are only available in the RAM code, such as the console_drivers structure . Don't assume you can just stop using it. It is that way for a reason, as I found out very recently with the qemu CAR changes.
Note that printk calls console_tx_byte, which does this: static void __console_tx_byte(unsigned char byte) { struct console_driver *driver; for(driver = console_drivers; driver < econsole_drivers; driver++) { driver->tx_byte(byte); } }
do_printk calls its very own console_tx_byte, which is this:
void console_tx_byte(unsigned char byte) { if (byte == '\n') uart8250_tx_byte(TTYS0_BASE, '\r'); uart8250_tx_byte(TTYS0_BASE, byte); }
So it's a lot more than just not calling console_tx_flush. These are not insignificant differences.
I am just trying to wave a caution flag here.
And I have trouble understanding you. Either we are looking at different source trees or it's too late at night for me to understand. Is there any variant of printk_* which does not use do_printk()? Or did you mean the two different variants of do_printk()?
You must take some care before you decide you can replace do_printk with printk. They're not even compiled into the same stage (or should not be).
If you want locking in do_printk, it will have to work in CAR. I actually think this is an area you need to be very careful in changing.
I firmly believe we can rig something up. It might involve a lot of v3 code, though.
Regards, Carl-Daniel