On Mon, Mar 12, 2018 at 10:37:28PM +0000, Jonathan McDowell wrote: > > If you want to work together you have to have a discussion. I appreciate > the bug has been languishing without a response but it pre-dates my > involvement with the OpenOCD package and it's not been as high priority > as getting the package up to date with upstream or dealing with security > issues.
Yes, I'm here for working together, for having a discussion. For creating concence. > On Mon, Mar 12, 2018 at 11:13:26PM +0100, Geert Stappers wrote: > > On Mon, Mar 12, 2018 at 09:39:29AM +0000, Jonathan McDowell wrote: > > > Is there a direct 1:1 mapping of devices that OpenOCD and urjtag > > > support, or is one a subset of the other? > > > > Seen the question, but I don't see where it fits in the discussion > > about a openocd file moving into seperate package. > > If one program is a strict subset of the other in terms of supported > adaptors then it may make sense for the program with the larger support > matrix to split a file out so that the other can take advantage of it. > If the 2 programs support different adaptors then I'm not sure of the > benefit; it becomes extra work on both parts to maintain the overlapping > list? The list will contain always more adapters then an user of openocd or urjtag has. So there is always that kind of "overlap". A JTAG adapter is hardware with JTAG electronics on one side and other at the other side. Example given: USB Both openocd and urjtag drive / control / manage JTAG adapters. That is the reason for an udev package that both packages can use. We are talking about a file with lines like ATTRS{idVendor}=="09fb", ATTRS{idProduct}=="6001", MODE="660", GROUP="plugdev", TAG+="uaccess" The VID and PID varies Now some odd text, I still don't get the set question. With 1:1 set for openocd and urjtag: all fine. Openocd set larger: urjtag is missing functionality Urjtag set larger: openocd is missing functionality Groeten Geert Stappers -- Leven en laten leven