[coreboot] locking...

[Carl-Daniel Hailfinger]

On 19.06.2009 19:33, Stefan Reinauer wrote:
> This is complexity from hell. Why not a decent locking mechanism.

I see no reason not to use locking if it actually works. That's the
reason I asked in the first place.


> Plus,
> reducing the incredible amounts of useless output coreboot produces even
> at DEBUG level.
>   

Worthwhile goal, but orthogonal to this discussion.


> Do we really want to re-implement IPC and shared memory in coreboot? I
> hear we are becoming a kernel.
>   

Not if it can be avoided. Shared memory may be good for big global
variables which we don't want to duplicate, but it should not be used as
a band-aid.


> ron minnich wrote:
>> I never got this done, I only got the "AP post code"
>
> v2 has / used to have working locking code since it was first ported to
> opteron. It may be that it broke while adding 5 more printks but it is
> there somewhere.
>   

Any hints on where to look are appreciated. I'd like to use locking
inside printk ASAP.


> Making the BSP poll for the APs (which is what we would do if we need to
> check the APs shared memory) basically renders the BSP unusable to do
> stuff while waiting for the APs.
>   

Agreed.


> With simple locking, everything can run in parallel, and only serial
> output needs to get synced. Which is what we actually want.
>   

As long as we don't perform byte-wise serial output locking (which would
defeat the whole purpose of the lock which is having readable messages),
I'm all for it. Show me the locking primitives and I'll add them to printk.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/