Rick Altherr wrote: > > On Jan 22, 2009, at 6:28 AM, Dick Hollenbeck wrote: > >> >> We have this global called cur_state that all the drivers are >> manipulating by direct assignment. This makes it hard to trap or >> watch these changes. I am proposing a pair of functions which would be >> used instead: >> >> >> set_current_state( tap_state_t ) >> tap_state_t get_current_state(); >> >> >> I am happy to do all the global edits to put these in. Then cur_state >> would be made static i.e. private. The value then is that we can add >> debug logging to the set_current_state() and get a good feel for state >> transitions when required. We have a nice debug facility in >> _DEBUG_JTAG_IO_ but nothing similar for state tracking. >> >> What do folks think? Would such a patch be accepted? >> > > I've been thinking along the same lines. I really dislike using > global variables like this. Are there any other globals that should > have accessors instead? > >> Any better names wanted? > > tap_set_current_state() and tap_get_current_state()? I can forsee > other parts of the codebase having a current state that requires > accessors.
Yes "tap" in name inclusion is an improvement. As you say, this will clean up the API somewhat, making it more academically correct. I like accessors because they let you trap manipulations of the accessed property in one place. With a compile time option we can have this gather up the calling file and line number also, that way the output will show where the state was changed. For somebody trying to program a foreign FPGA or CPLD device, this state tracking will be very helpful. I cannot give you a clean patch now, because my tree is modified with my previous patch submissions. I can wait until those are committed and then give you a clean patch in a couple of days. I wonder if we need the "current" in the accessors names. tap_set_state() tap_get_state() might be sufficient, reason being simply the length of the function name is getting out there quite long. But either will do for me. Dick _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
