On Tue, Dec 1, 2009 at 9:03 AM, Zach Welch <z...@superlucidity.net> wrote: > On Tue, 2009-12-01 at 08:52 +0100, Øyvind Harboe wrote: >> > How about a warning when it's _not_ explicitly enabled or disabled by >> > the user? Specifically, tell the users to try enabling those features >> > or to add explicit commands to stop the warnings. Scripts for boards >> > where that feature will be safe by default could add the required >> > commands, and users for others will be able to read the documentation >> > for those commands decide for themselves. >> > >> > This keeps the default safe while giving users the nudge in the >> > direction that you feel they will want to be headed -- eventually. >> >> I think this is a good way to go forward. >> >> Here is a though on implementation: each target defines a default >> post-reset script, there is some suitable event that exists currently >> I'm sure. This post reset script does checks and prints out >> hints and warnings. > > Anything that requires defining a new default gets a frown of > disapproval from me. That breaks backwards-compatibility, which is > another reason not to change the default without more consideration and > wide-spread testing. A warning in the C code should be enough to induce > that desired outcome, if you also tell users to report their results in > order to help us decide whether to enable it by default.
You misunderstand. I would like to see a default tcl handler added that can be overridden. This tcl handler would not change anything, just do checks and print warnings. No change in defaults. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
