On Sat, 2009-11-28 at 16:36 -0800, David Brownell wrote: > On Saturday 28 November 2009, Zach Welch wrote: > > I believe that the real problem is that the .mode initializer for those > > commands' registration records have been marked incorrectly. There may > > be others.... It's easy to discover which ones need to be fixed, but > > that does not sound like the only problem. > > Maybe part of the problem is that putting the "init" on the command line > with a bunch of other commands. I have startup scripts, some of which > tweak things on the command line and some of which do it in a per-board > setup.cfg file ... small sample of two shows the former breaking but not > the latter.
Yeah, I figure there are some scripts (or users) that have not been sufficiently strict about CONFIG vs. EXEC modes, as that logic has been broken for ages.... Nevertheless, the very design needs to be improved. Indeed, this feature presents a layering violation. Right now, the command layer knows too much about the state of initialization. Even a simple 'enable/disable' state would be a sufficient generalization of the intended functionality; however, many commands should be registered only once they can be used, which we do in very small doses today. Why not allow the user to bring up an interface once its defined? Specifically, the 'init' command might be a subcommand associated of a specific (named) interface device instance. It would give other commands for configuring the TAPs, devices, and targets associated with that interface. Naturally, this implies multiple interface support, so OpenOCD can support gang-programming and multi-head test applications. Naturally, it should be possible to run 'init' interactively, such that one can startup OpenOCD without any interface defined. That change should be possible independently of other work in this area. I seem to recall the topic being discussed in the past, but I can't find anything relevant in my local archive after a quick search. As I see it, the notion of command modes can be eliminated entirely, if we are careful in how we restructure the command hierarchy. Indeed, I should have articulated this impetus in my post on the topic; however, effecting this all correctly will require tremendous amount of work. --Z _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
