On Sun, 2009-10-25 at 12:31 +0100, Øyvind Harboe wrote: > You make excellent general points in your post and I agree > to what you are saying, however here I'm discussing mrc/mcr > specifically and how to proceed with that one. > > Did you read up on mrc/mcr in targets and consider > the current patches & changes in detail?
Am I wrong in my assertion that these commands are ARM-specific and do not belong in target.h? That seems like one reasonable objection for holding off with integrating this series. I think it is preferable to identify and implement a suitable architectural remedy first. The same goes for MMUs and phsy/virt callbacks, to a lesser extent. Presently, my gut tells me these changes have planted trees in an unhealthy part of the forest. We should be clearing the deadwood and restoring balance to our ecosystem, after getting a bird's eye view. Concretely, I would like us to consider prefacing this kind of development with updates to the "target architecture" section of the developer manual, rather than discussing it on the mailing list. Proposals via patches, updated just like a patch series. For now, the developer manual documentation lacks sufficient architectural details to provide the high-level perspective required, so we cannot claim to have a clearly conveyable view of the current system architecture (or its strengths and deficits). As such, your patches cannot be objectively considered until this has been remedied. While a doc/manual/target.txt section would be good, documenting our existing architecture more completely is one path for lowering resistance. As for the code... there are dozens of simple cleanups that could be made to the existing code. While comparatively trivial, the additive effect of such refactoring would benefit the architecture tremendously. If I get the opportunity, I will tackling these through series like the one I just posted on repo.or.cz (parsing-cleanup in openocd/ztw.git), but others have helped with this too. > If you still disagree with my piecemail approach after having read > up on the mcr/mrc details, then I'll be happy to go along with > whatever you propose from a general git/patch/branch > development point of view on the mcr/mrc case. I assume you are speaking of implementing as much as possible but still expecting a gradual cross-over. I understand the need for others with the right hardware to develop part of the series, but the principle stands intact. The effort should focus in a fork of the repository -- not in the master branch. In fact, you should probably expect to wait at least a week or two for other developers to step forward and submit the patches that finish your series (after cajoling them every couple of days on the list). Sure, you might eventually settle for less than successful 100% migration, because old platforms will die. However, there should never be a rush to push upstream, because you can always track your own patches locally. Incomplete series detract from the integrity of the master repository revision history, when compared to merging complete, polished, and signed-off branches into a linear version history on the master branch. > If I have to commit to doing *all* the work before I start > any mrc/mcr work at all, then I'm loathe to start at all and > I'd rather just revert the changes I've done so far. I am not advocating any particular resolution, and I would rather see us continue to move forward. That said, I have considered the possibility of asking to remove them to a branch for the time being. I know that would seem discouraging, but it could be positive than retiring the old commands and fixing any outstanding bugs. I can't judge that from here. 1) It could move us toward 0.3.0 faster. 2) The architectural problems can be handled first. 3) Other developers can contribute to a public branch to finish it. With GIT, more development should flow from and around the main repository than to and through it. So yes, developers must be made to finish their work in their own repository before the project merges it. Forcing you to do it in your own repository, always chasing the master, is great incentive to get it done. Since 'git rebase' makes this process painless, it should mean that work gets fully finished and tested before getting merged. There should never be a rush to push new features like this, particularly when further discussion points out that there may be better alternatives. For now, you should chose to merge your remaining patches or revert the initial patches. Sufficient architectural questions have been posed to suggest that they probably deserved to be removed for 0.3.0, but I leave it to you (or the mob) to decide. Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
