[coreboot] locking...
Carl-Daniel Hailfinger
c-d.hailfinger.devel.2006 at gmx.net
Sat Jun 20 03:05:45 CEST 2009
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
--
http://www.hailfinger.org/
More information about the coreboot
mailing list