[Openocd-development] Cleanup in target.c
This is some thoughts on cleaning up target.c and specifictarget relations. It is not an architectural change, but rather about consistent use of the one we have. A very common pattern is to have something like this target_halt(target_s *target) . Some common cleanup and sanity checking . calling out to: target-type-halt(target) The consequencies should be that: - the specific targets does not have to do general sanity checking that is not unique for a specific target. - target-type-halt(target) should never be called from any other function than target_halt() - the specific implementation of halt() can be called from within the defining module If you work through these issues I am sure that you can make it easier to implement new targets, where onle the really target spicific thins has to be rewritten. Regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cleanup in target.c
Øyvind Harboe wrote: I think this makes sense. It is roughly along the lines of using a base class where the subclass implements the guts and the base class implements the fn called by normal users. Along the same lines, Michael Bruck was trying to find a reasonable way to reuse the instruction simulation for arm11 so we could get single stepping support for all arm11 targets... I believe that Zach is trying to round up a 0.2 release soon though. Could be good to do this afterwards. With a 0.2 out of the door, it should be easier to do these sorts of things in svn head. Yes, and no. Many of these changes are only debug messages, so I would categorize them as cleanup without functional impact. So the need to be conservative is rather small here. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cleanup in target.c
Yes, and no. Many of these changes are only debug messages, so I would categorize them as cleanup without functional impact. So the need to be conservative is rather small here. OK. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
