On Sun, Oct 25, 2009 at 4:11 PM, Zach Welch <[email protected]> wrote: > 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.
Your assumption is correct, but it is unreasonable to hold of all work until the interface problem can be tackled. It's a completely separate problem and once solved, the mrc/mcr stuff can trivially take advantage of any scheme worth it's salt. > 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. Whenever a solution to the more general interface problem appears, then I would love to use it. The mrc/mcr stuff isn't trying to address it. > 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. Nobody has posted anything of substance about working on the interface problem. So far we've identified it and have a bit of understanding of it on the list. I'd love to see this cleaned up... Am I correct in assuming that you will not be diving into the mrc/mcr issue speficially and that you are addressing only the more general problem of how to handle branches & the general interface/code cleanup problems? Specifically for the mrc/mcr problem do you believe it would be realistic to develop it in a separate repository and still see testing? The mrc/mcr code touches none of the existing commands/code, and it is not yet documented. The chances that 0.3 users will know about it or care are slim indeed. I don't agree with you in general and I'm working on my branch + multiple repository skills, except that I'm concerned that we're too small to spread out testers across several repositories. What to do with mrc/mcr speficially? Since it's completely parallel to existing commands I don't think 0.3 users would become aware of these work-in-progress commands. I seriously doubt that any normal user would be able to tell the difference whether the wip code is there or not. My plan was: - commit the remaining patches. I don't think it matters one way or the other. - get arm926ejs tested & retire cp15 commands, possibly adding small tcl proc's to demonstrate syntax/provide alternate interface - get the rest of the old cp15 commands similarly retired - hopefully along the way someone will pitch in w/the remaining targets or I'll find the courage to attempt e.g. xscale... Also input from Magnus Lundin was great as it can point to perhaps better naming of commands and such, which really are trivial code changes that make documentation better and improves ease of use. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
