Hi Øyvind, Yes, you are absolutely correct that configuration files are a lot of work to put together. And I might add critical too! :)
One of the things I wanted to do is throw out some ideas for everyone to think about as possible improvements to this configuration file development process. Some of the ideas are philosophical and don't have a right or wrong answer. They really are more intended to provoke a thoughtful discussion even if they are never implemented: 1) One of the features that the software currently allows is configuration setting inheritance from board to target to CPU. While I generally am a big advocate of extensibility in most software projects, I have been very leery of doing this for hardware-specific configuration files. Over every person's career, many of battle scars are left behind. And I have many on mine that were related to nightmare debugger/emulator configuration problems where I tried to inherit one thing from another. The one danger with inheritance in this particular scenario is many people will see a target and naturally glom onto it without giving too much thought about the consequences. Many processor families have rather incestuous relationships that share many common details, but inevitably have differences -- often very subtle ones. These little details, however, sometimes generate big consequences. The other danger always lurking with the current approach is that it is entirely possible one developer can make a change to the underlying root target file without realizing that it may propagate undesirable changes into higher-level board files. Unfortunately these type of issues are not typically discovered until much later. For these two reasons, I wonder if it may not make more sense at some point to discourage target configurations all together and encourage self-sufficient board-level configuration files instead, even though this normally goes against the grain of extensibility. The key to making this work would be to break the directory structure along processor models/manufactuer (i.e. arm926-ejs/atmel) and then lump individual board configuration files under the appropriate directories. If a developer plans on using a particular processor in a design that doesn't have an existing debugger configuration file, they quickly know which board configuration files are likely to be similar and then clone it with little risk of clobbering something else. 2) One possible process improvement that I believe makes sense is to start enforcing a rule that authors of new configuration files must include a minimal comment header at the top of the file that specifies the exact hardware/debugger combination used. The SAM-ICE (J-link) debugger I am using for example has a number of internal quirks that may not exist in other brands and vice-versa. Here again, it is possible for another developer to come along and use a script with another debugger, find something that appears to be a bug, and make a fix for their particular setup that now breaks it for the original setup. If for some reason, the approach described in 1) is adopted in the future, the approach could further be extended by creating additional subdirectories for emulator and version. For example, the configuration file I created would be filed under "arm926ejs/atmel/at91sam9g20-ek/sam-ice/v8/file.cfg" or something similar. This way if a developer is using a future version 123 dongle that has new quirks, there is less risk of corrupting older debugger configurations that other people may still be using. 3) One feature that I think may make sense to add at some point in the future to the main software is support for label/value associations that allow hexadecimal register values to be associated with more legible and understandable names. Looking at "mww 0xffff3ec2 0x2" in a configuration script is more likely to introduce mistakes during reuse, then say "mww some_xyz_register 0x2" where the name of the register clues you into what it does or at least where to find it in the datasheet. Anyway like I said, these ideas I propose are just that and nothing more. I realize that other good arguments exist for keeping things the way they are and there is nothing wrong with that either. And admittedly, the ideas I propose here have their own share of thorns too! Food for thought! :) Gary On 8/31/09 2:09 AM, "Øyvind Harboe" <[email protected]> wrote: > Committed. > > Thanks! > > I think you are raising an important point: these configuration > files can be a *LOT* of work to put together and hard work > too... > > I don't know of a shortcut, other than to try to build an extensive > library of quality config files. Of course I'd like all the config > files to be of top quality tested by multiple developers, but > "quantity has a quality all of it's own"... We see evidence > that bad config files are being incrementally improved by patches, > hence I prefer to get them committed sooner rather than later. > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
