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.
> 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 ...
> 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.
> 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.
- Dave
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
