On Monday 22 June 2009, Zach Welch wrote:
> On Mon, 2009-06-22 at 19:59 +0200, Dominic wrote:
> >
> > Øyvind mentioned the idea of wrapping the JTAG API in TCP/IP. Aside
> > from performance implications I think this would require some
> > significant development efforts with little immediate benefits. Even
> > worse, it would encourage other JTAG interface vendors to implement
> > their JTAG interface layer as a binary only driver that talks to the
> > OpenOCD via TCP/IP layer, too.
FTDI doesn't see themselves as a JTAG interface vendor though,
and that's part of the problem. :(
Getting more driver support wouldn't be entirely bad, would it?
Most of those JTAG adapter vendors are just ignoring OpenOCD
right now. Maybe they talk to GDB through a proprietary GDB
server engine; maybe they don't talk GDB at all.
We could be presenting a choice between getting GNU tools
support by either
(a) writing proprietary JTAG engine *AND* proprietary
GDB server engine; or
(b) writing proprietary JTAG engine but *REUSING* OpenOCD
GDB server engine.
Anyone switching to (b) would necessarily start improving
the OpenOCD code. And they'd likely realize that adding
Linux support -- instead of being Windows-only -- became
much easier. That's in addition to
(c) propietary JTAG engine plus proprietary non-GNU tools
Vendors now in category (c) that provide such OpenOCD
engines seem like incremental wins too. But if any of
them do so, I'd be (pleasantly) surprised.
> I am opposed to this as
> well, for the same reasons. This is why I did
> not suggest it until someone else suggested it. I want to see libusb
> and libfdti fixed,
I think *everyone* wants to see those get fixed.
"How" is open; Duane's WinUSB note was interesting.
> and I do not want to open the door to more binary
> drivers. If I were to implement the TCP/IP interface without pay, I
> would release it under the GPL to prevent this situation from ever
> occurring. At this point, I am tempted to implement it simply in order
> to close this back door to binary drivers.
It wouldn't work that way at all. As soon as there's a well defined
protocol, it could be re-implemented without using your code.
There are two ways to take that reality. One is the Microsoft way:
as a threat, to be responded to by ensuring the protocol is always
changing and abysmally documented, so that interop using anyone
else's code tends to be weak in critical areas.
The other is the IETF/Internet way, to be responded to by making
sure the protocol is well-documented, well-behaving, and evolves
cleanly. This is how we got HTTP and SSL, not to mention TCP in
the first place.
- Dave
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
