On Thu, 2009-05-21 at 21:43 -0400, Duane Ellis wrote:
> Zach Welch wrote:
> > Hi all,
> >
> > I feel like this is a "dumb question" but here goes.... Why aren't all
> > of the TCL configuration files (src/target/{target,board,interface}/*)
> > located in src/target/ instead of src/tcl/?
> >
> >
> I presume you mean this: "why don't we just put all the files in one
> monolithic directory full of files".
No, I meant moving the directories themselves into the tcl/ directory.
I definitely want structure, and more than we have.
> In the past, what we had was mostly monolithic config scripts... new
> users (who where writing board configs) would toss up a configuration
> file - that was monolithic. What they did not see was the 'parts' of the
> configuration file. ie: The interface specification, the chip
> specification, and things specific to the board (ie: which type of SDRAM
> or external FLASH do you have).
I am against monolithic files, given the ability to virtually eliminate
duplication of code with proper [find other.cfg] structuring.
> The exact organization really does not matter to me, but the sub-folder
> separation is really important.
I agree 100%.
> Think of it as "visible architectural separation". By dividing the
> configuration files into 3 different parts (interface, chip, board)- to
> a new user of OpenOCD struggling to get a config file working its hard
> to understand all the pieces to the puzzle.
We could take it a step further and provide very fine-grained files:
src/tcl/<hardware>/<family>/<part>/<version>.cfg
This would take some time to get right, but it would be worth doing.
> Think of it as "human (mind) factors".
>
> =
>
> I too do not like the idea that there are "3 different roots one might
> find tcl files in".... that is an entirely different matter, cleanup
> perhaps would be good.
This was actually the point of my original suggestion. :)
> ie:
>
> scripts/interface
> scripts/chip
> scripts/board
> scripts/helpers
> [etc...]
Right now, we have src/tcl/*, so that is lower-hanging than 'scripts/'.
Also, 'tcl/' says what those files should be. I think 'tools/' is where
other kinds of "scripts" should live.
> FYI - if you are in a "cleaning mood" here are some other ideas.
> ===
> Example: "target->type->write_memory()" - could be refactored, 116
> locations.
> samething: read_memory() - 35 locations.
> if( !target->type->examined ) -> 24 locations
>
> I am a firm believer in "access functions" - (macros are ok) but access
> functions are important.
static inline functions should be preferred over macros, yes.
> Try this "grep" across the source code
>
> egrep -nH -e '([a-z]+)->([a-z]+)->' *.c */*.c
>
> ===
> Example:
>
> The "scanfield_t" type - has no *common* initialization (zero) function
> or macro, ie:
>
> scanField_Init( &scan_field );
>
> This means that if somebody "added a feature" to the scan field structure
> There is no means to "default" new fields to a 'safe' value.
> For example: a "char *debug_log_field_name"
> The "init" function could set it to NULL - ie: 'un-named'
+1 from me.
I like these ideas and will try to get to them before the window closes,
unless someone else wants to volunteer to do these in the meantime.
Otherwise, I'll put them on The List.
Cheers,
Zach
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
