[coreboot] locking...

[Carl-Daniel Hailfinger]

On 19.06.2009 18:35, ron minnich wrote:
> On Fri, Jun 19, 2009 at 9:13 AM, Myles Watson<mylesgw at gmail.com> wrote:
>
>   
>> Another option would be to only let the BSP print messages by default.  That
>> would clean up most people's logs most of the time.
>>     
>
> yes, that is why I did that struct-based stack in my v3 SMP startup.
> The struct formed the base of the AP stack. We could put a simple
> print buffer in there and require that the BSP print out AP boot
> messages. This would be a bit better than trying to resolve this
> locking issue.

Neat idea. Should we make printk on the BSP check AP buffers after each
printk and print them as well? What happens if the APs print stuff
faster than the BSP can poll? By the way, managing that buffer is a
locking problem as well, but we might get away with it. The bigger
problem with AP buffers is that they may be invisible to the BSP if the
APs have independent cache.


> I never got this done, I only got the "AP post code"
> working. But overall I think my SMP startup prototype was much cleaner
> than what is in v2 today.
>   

I don't understand v2 startup anyway (well, except for your new code).


> I don't think we want to put locks in printk. If an AP gets part way
> up, takes the lock, and fails, everyone is going to stick on that
> lock. Not fun.
>   

If we can get locking to work, auto-busting a lock is almost trivial.
Try to get the lock for n iterations, after that print anyway and
complain "lock held too long".
Give me a trylock() function and I'll give you auto-busting code.

> We have made a decision that the BSP is always assumed to work. Any
> strategy should be build around this assumption, and the further
> assumption that we ought to contain the AP so that it can not prevent
> the BSP from doing its job.
>   

Absolutely agreed. Auto-busting the lock would solve this nicely and
even detect hangs.

Regards,
Carl-Daniel

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