On Sat, 2009-11-28 at 18:16 -0800, David Brownell wrote: > On Saturday 28 November 2009, Zach Welch wrote: > > > > 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.... > > Broken how? It's worked as advertised, as far as I know.
It was allowing all commands to run during CONFIG stage, regardless of whether they were marked EXEC-only. Broken. > > 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. > > And I'd like to see things that *can't* be used not even be displayed > in the "help" list ... I had a patch to do exactly this, but I think I dropped it. It's a two-liner though. > > 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. > > I'm not keen on that. It already supports multiple scanchains ... just > put each one in its own process. That's not something that's broken. > Not that I'd object hugely to having it; but it just seems like it would > only increase complexity, to no real benefit. Multiple processes will not allow easy synchronization when testing targets that are connected via multiple interfaces and to each other. Moreover, it's far more difficult to start two processes: you have to set their server ports manually, or they conflict. One process is the way to go for testing scenarios that require multiple interfaces. And it should eliminate 99% of the global variables in the jtag module. Proper encapsulation of that layer would be a real benefit in my eyes. > > 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, > > Yes it could be. But right now we're faced with just a regression, > where adding > > -c init -c "poll off" > > to a working comand line causes things to fail. When I started to look into this, I decided to start a new series that factors the init process into several fine-grain commands. The current command does _far_ too many things under the covers, making policies when it should be offering mechanisms. For example, the gdb_init routine can be factored into routines that allows starting an GDB server associated with a target at any time. While this work can retain the current syntax, the underlying mechanisms will be prepared to switch to a more policy-neutral command language. --Z _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
