On Sun, 2009-10-25 at 11:17 +0200, Øyvind Harboe wrote:
> The default implementation of target_read/write_phys_memory
> is to call target_read/write_memory, but I'm thinking the default
> implementation should return an error and
> LOG_ERROR("Not implemented").This makes a certain amount of sense to me, but it does point out the fact that some targets do not have an MMU. Is that feature worthy of abstracting away from the core target support? Probably, but many lesser evils should be banished before attempting a proper solution to that nightmarishly grandiose proposition. > Users can then discover the missing target support, stop searching > for it elsewhere, report it or even pitch in to get it added. Combined with the above, we would need to distinguish between the two different cases: "not yet implemented" and "cannot be implemented". > The optional [phys] argument to mww/mdw variants is still there for > *all* targets though, even if they can't support it in principle > (there aren't any Cortex M0/M3's w/MMU are there?). It should detect and report the correct situation, as above. > Which brings me to another thing... > > Should commands that *could* be supported by targets be added > even if the OpenOCD target code does not support it them? > > If users are searching for the right way to do mrc/mcr operations > for, say, XScale, would it not be better if the command was there > but returned "not implemented"? Users should see commands for targets that can be supported, and commands that a target will never support should be hidden. If a user tries to use a command that should be implemented but isn't, then they can report their attempt so we may prioritize (or be reminded of) their required implementation. If support for a feature must be probed, that information could be used to influence the UI more. In the real world, we want to KISS with our command handling code as much as possible, so a good solution will strike some balance between the extremes. To wit, the parsing code can be made to fail gracefully when requested features are found missing, but adaptive help strings would be going too far (for now). This all said, we should avoid pushing new features that have not been fully implemented in the first place. :) Cheers, Zach _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
