[coreboot] locking...

[ron minnich]

On Fri, Jun 19, 2009 at 5:57 PM, Carl-Daniel
Hailfinger<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 20.06.2009 02:39, ron minnich wrote:
>> On Fri, Jun 19, 2009 at 4:46 PM, 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.
>>>
>>
>> it's very useful. It can be used in the rom/CAR code before consoles
>> really work.
>>
>
> Hm. AFAICS both versions have the same console requirements and just
> differ in locking (if you ignore the _flush no-op).

not at all. They are quite different in purpose as my earlier email
points out. printk prints to all console_drivers and is intended for
use when RAM is up and working. do_printk is meant for pre-RAM usage.

I actually did not write any of this stuff, but I got acquainted with
it in the last two weeks.

> True, but our console requirements for both versions are pretty minimal
> and I think we showed in v3 that a one-size-fits-all printk can work fine.

I do not recall that v3 printk was heavily tested with smp. In fact
it's not smp safe from my reading of the code.

v3 printk looks most like do_printk in v2. Part of the reason is that
we had decided, long ago, that the v3 console would only be serial. So
we gave up the flexibility of v2 but gained
simplicity.

Actually, I can verify that v3 printk works badly on multi-core, since
I saw the intermixed output during my abortive attempt at getting core
2 going on v3. v3 does NOT solve the problem.

I'll say it again: getting this right is going to require careful
thought and ripping up of the first couple ideas. It only looks
simple. CAR makes things a bit messy, and the wide variant in CAR
behavior among different vendor's CPUs makes it really messy. One size
will NOT fit all.

ron