Carl-Daniel Hailfinger wrote:
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).
Then please go ahead and learn to read it... It's important that we understand what's going on before changing it.
The new code just duplicates what was there, but it adds a couple of new breakages. It doesn't even add any conceptional differences.
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.
Please, please, don't get fancy. There's no real problem, we've just been doing too much cut and paste in the past without testing the new code. This made us end up with different versions of printk, some with locking, some without. And, no, porting the code from v3 over is not an option at this point. It does too much different stuff. Let's rather start dropping unneeded implementations in v2 until things look sane again and then we can decide what implementation we want.
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.
I'm not sure I can interpret this into the above sentence. What would lock auto-busting gain us? We'd be debugging printk, but nothing more?
Stefan