On Sat, 2009-10-24 at 15:03 +0200, Øyvind Harboe wrote: > Attached are the remaining patches for the first round of > target->type->mcr/mrc support. > > There is a writeup in TODO of the harder targets > that remain. E.g. arm966e support requires good knowledge > of that target + ideally access to test hardware, so that's not > something I can or should attempt at this point. > > Old cp15 commands still work and should only be retired once > the new mrc/mcr can be tested on actual targets.
If there are existing commands, then this feature definitely should have been committed once it was complete, after a series of patches to gracefully cut over to the new system had been developed and tested. There many "improvements" to make, but your proposed patches create avoidable code duplication. I started to eliminate these problems types of problems, but it gets hard to stay motivated on that task when the goal line keeps moved back like that. I am striving to gain a better perspective of the system at this level, but it seems that your present implementation weakens OpenOCD's architecture and thus creates a new barrier to improving it. Obviously, I am not trying to discourage you from continuing to work on these features, but this should underscore the notion that only complete and reviewed work should be pushed. Whether during development or testing, incomplete or experimental patches should be processed outside of the main SF.net repository. > It would be great if I could have this tested *before* > a release, but the test cycles of OpenOCD(identify > a user who has a target and is willing and able > to test) are long enough that I would be pleased if > all targets could have tested mcr/mrc interface > in the course of a few months and a release or two... Please publish a mirror on repo.or.cz and push this branch regularly so others can pull it for testing. > This whole mrc/mcr thing is about driving > OpenOCD in the direction of polymorphic interfaces > at the C and command level, ref recent "mww phys" > work. Is this the right level though? Anything that is specific to ARM should not be in target.[ch]. > mrc/mcr commands are only added if the target->type > supports mcr/mrc. That way help isn't quite as cluttered. > Previous behavior was to fail when executing the > commands. Definitely an improvement, but is it possible to architect the target layers such that only devices with it have the callback at all? Cheers, Zach _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
