On 19.06.2009 18:35, ron minnich wrote:
On Fri, Jun 19, 2009 at 9:13 AM, Myles Watsonmylesgw@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