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



More information about the coreboot mailing list