Andy Green wrote: > Qi lacks any ECC support right now and going forward it looks like we > don't even need NAND support in it. So we would be adding it just for this.
That's true, yes. Even if abandoning the NAND as much as possible, we'd still need ECC support to reliably load qi from NAND itself. We could avoid this if the probability to hit a page with only a single-bit error is very low when loading qi, but I'm not sure this is a good assumption. > BTW when I tested the current stable-tracking which is 2.6.27-rc5+, I > tried starting a rootfs and jffs2 blew chunks on it. I think what happens is this: - the wrong ECC algorithm finds lots of problems, as one would suspect - most of them look like multi-bit errors and are silently ignored (JFFS2 has its own CRC and doesn't use the ECC statistics from MTD) - however, some look like single-bit errors. MTD then tries to "correct" them. - JFFS2 complains about these because the CRC is wrong. - after that, a swift and merciful death is all you can hope for :-) > All but one IIRC came out in the device tree re-ordering. Great ! Let's hope the monsters there stay dead for once ;-) > That answer came out very smoothly, but I am not sure you quite > understand what the current set of branches are for. Hmm, I read what you wrote twice and I see the logic in it. However, I don't see how this would be better than just doing the cleanup right away. Deferring the cleanup until it comes back from upstream only means that - bug fixes will have to be cherry-picked between the parallel branches, - there will still be a big merge at the end, with cleanup and new development both contributing to the differences, - developers working not only in their own corner have to keep track of both branches, - and any problems in the cleanup itself will only be found much later when they're coming back. So I don't really see the benefit. It's just more work, more mistakes, and you'll have to come back and remember tasks months after they were finished. Also, cleanup is not just art for art's sake but serves the very real purpose of making the code easier to understand and to maintain, which would also benefit any new work on the main branch. By the way, while I admire your ability to keep all those parallel branches from becoming one tangled mess, I don't think we have to be afraid of tracking upstream a lot more closely. Tracking upstream is hard at the moment, because there are so many places where we can conflict, and because other developers break things we depend on because they don't even know our code exists. Since upstream gets a lot more exposure than Openmoko kernels, any bugs that aren't our own making will get fixed there more quickly, and we save the effort of searching for fixes to cherry-pick and the cost of missing them. So it's good to update frequently, and to reserve large-scale branching for those cases where you only fix the truly cataclysmic failures and document the rest. - Werner
