[coreboot] locking...

ron minnich rminnich at gmail.com
Sat Jun 20 02:50:57 CEST 2009

On Fri, Jun 19, 2009 at 5:17 PM, Stefan Reinauer<stepan at coresystems.de> wrote:
> Carl-Daniel Hailfinger wrote:
>> do_printk is defined in src/arch/i386/lib/printk_init.c as almost
>> identical function, but without console_tx_flush and without locking. If
>> only one CPU uses the lockless variant, we lose.
> This is the version that was intended to be used when CONFIG_USE_INIT is
> set.

reminder. do_printk is (or should be) used ONLY in the CAR code. 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++) {

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.

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


More information about the coreboot mailing list