[coreboot] locking...

[ron minnich]

On Fri, Jun 19, 2009 at 5:46 PM, Carl-Daniel
Hailfinger<c-d.hailfinger.devel.2006 at gmx.net> wrote:

> _flush calls tx_flush for each driver, but all console drivers in the
> tree lack such a tx_flush function, so it's essentially an expensive
> no-op because all console driver structs are walked each time.
> Kill?

no. It does no harm. And we may need it someday.
The structure of it makes sense.

>
>
>> Other than that, we could unify those versions by just defining an empty
>> (for now) version of the spinlock functions in raminit stage. Then think
>> about where we can place our locking for those platforms that need it
>> this early...?
>>
>
> Sounds like a plan.

it's more than spinlock.

you must also fix the use of the console_drivers struct. There are
several things you need to get right to make this work.

I am not sure I see the point. You're going to make lots of changes
and in the end, using cpp magic, have a unified function which acts
differently depending on how it's compiled.
eek.

It makes the most sense to me to have a RAM printk and a ROM printk
which are for different purposes. They already share the most
important common piece, which is vtxprintf.

But if you insist on unifying them you need to read the two parallel
functions carefully and I guess do the #ifdef dance.

> So we'd get uninitialied data for any pre-RAM spinlock access? The v3
> global variable mechanism should solve this nicely. At least it was
> designed for that.

Again, please look at this code and make sure you know all the
differences before you tear the wall open :-)

ron