On 19.06.2009 19:41, Stefan Reinauer wrote:
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.
I tried multiple times and gave up after it became obvious that v3 startup did similar stuff, but was a lot more understandable. I suck at understanding linker scripts. Lots of linker symbols and scripts and other funky trickery combined with code includes made the code unnecessarily hard to read. I know you understand early startup very well and I admire that.
Anyway, given two code versions A and B which seem to be functionally identical, but only one of them is easily understood, I'll always opt for replacing the complicated version with the easy version unless there are technical reasons not to do so (broken functionality etc.).
The new code just duplicates what was there, but it adds a couple of new breakages. It doesn't even add any conceptional differences.
Even if the differences are only conceptual, the coding style (and the IMHO over-usage of linker magic) is so radically different that I dread the current v2 code (well, not the brand new stuff from Ron). Once I know what's broken with the new code, I actually have a chance to understand and fix it.
Firmware is magic. Early CPU startup is even more magic. (I mean this in the best possible way.) We are magicians, but some of us are more advanced than others. I'm still learning. Having code which is understood by more than one magician is good. Don't get me wrong, I'm not advocating dumbing down the code, but if we have functionally equivalent code variants, the more readable/debuggable variant should be used IMHO.
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.
The v3 printk has some neat features over what I can see in v2, at least from what I remember offhand: - detection of NULL dereference (helped find a bug) - detection of near-NULL dereference (same) - detection of non-ASCII characters in case of corruption (same) - reuse of vtxprintf for sprintf and printk - printk buffer - multiple output devices: USBDebug, Serial, Buffer
Since my intention is to keep v3 alive and to improve v2, I want to make very sure that we find out what the best variant of printk is (this may well be a fusion of v2 and v3 functionality), then have both versions use identical code. If there are technical reasons not to do so, I'd like to hear about them.
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.
I had assumed the v3 printk was universally better than all of the v2 variants. Unifying all v2 printk would indeed be a huge step forward, but as long as I don't know which features we want, I risk eliminating the wrong variants. One thing v3 seems to handle better is multiple output modes (USB Debug, Serial, Buffer), where v2 seems to have sprouted a printk variant for each.
What would lock auto-busting gain us? We'd be debugging printk, but nothing more?
Sorry, it was a bad idea to bring up, mostly addressed at worries that printk may hang. Though if that happens, we have much more pressing problems than locking. Please forget I brought up lock-busting. Thanks.
Regards, Carl-Daniel