)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"f522862099827e484b75f9271b7e692c19ce0555","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"29a96553_2174d5b9","updated":"2026-06-08 17:06:50.000000000","message":"The command name `remote` has sense for TCP, much less for a unix socket that is a local connection.\nOther adapters have similar needs:\n- rshim.c have `rshim device /dev/rshim\u003cN\u003e/rshim`\n- xlnx_pcie_xvc searches for `/sys/bus/pci/devices/%s/config`\n- xlnx_axi_xvc has `dev_file` and `dev_addr`\n\nIt would be nice to have a more generic command name in place of `remote`.\n\nThen, since the `enum adapter_remote_type` could have new values for the adapter above, don\u0027t assume the enum only has two states. In next patch remote-bitbang you wrote:\n```\nif (type \u003d\u003d ADAPTER_REMOTE_TYPE_UNIX)\n\tremote_bitbang_fd \u003d remote_bitbang_init_unix(address);\nelse\n\tremote_bitbang_fd \u003d remote_bitbang_init_tcp(address, port);\n```\nthat will not work properly once the enum gets more values. Use instead a switch/case that fails on default unsupported case.","commit_id":"f94a28d2649ef89105a56940581995074aff03bb"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"201d0630dfa693813daf6a1b9dc9927c11dcbcaa","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"960b5b43_2f690278","in_reply_to":"29a96553_2174d5b9","updated":"2026-06-09 13:01:52.000000000","message":"Thinking over about the command name.\nGDB uses commands `target remote` and `target extended-remote`, also for local socket or local console.\nI think we can keep it with this name too.","commit_id":"f94a28d2649ef89105a56940581995074aff03bb"},{"author":{"_account_id":1000853,"name":"zapb","display_name":"Marc Schink","email":"dev@zapb.de","username":"zapb"},"change_message_id":"f1641ce1fc1202e5a753ff600b26d2f9c4471935","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"e5faff89_bfd0cbfe","in_reply_to":"960b5b43_2f690278","updated":"2026-06-10 10:59:45.000000000","message":"\u003e The command name remote has sense for TCP, much less for a unix socket that is a local connection.\n\nI had the same feeling, but for TCP and UNIX sockets, it\u0027s acceptable I think.\nIf we extend this command to support other connection types, I\u0027m happy to rename it.\n\nHere are some alternative name suggestions:\n\n- `adapter resource`\n- `adapter location`\n- `adapter endpoint`\n- `adapter address`\n- `adapter uri`\n\n\u003e Other adapters have similar needs:\n\u003e\n\u003e - rshim.c have rshim device /dev/rshim\u003cN\u003e/rshim\n\u003e - xlnx_pcie_xvc searches for /sys/bus/pci/devices/%s/config\n\u003e - xlnx_axi_xvc has dev_file and dev_addr\n\nIf we extend this command to support these connection types, we should also include USB devices. This would allow specifying USB device locations or VID/PID pairs. I don\u0027t see a reason to exclude USB - is there one?\n\nAnother important question: Should we introduce a prefix for TCP/IP connection types (e.g., `tcp:`) when expanding this command to cover \"non-remote\" connections?\nThe sigrok project\u0027s connection parameters [1] could serve as inspiration.\n\nAlso important: Is extending this command part of your roadmap **before** the v1.0 release?\n\n[1] https://sigrok.org/wiki/Connection_parameters","commit_id":"f94a28d2649ef89105a56940581995074aff03bb"},{"author":{"_account_id":1000853,"name":"zapb","display_name":"Marc Schink","email":"dev@zapb.de","username":"zapb"},"change_message_id":"1413ed1abf0f25013eb75d18974ab6231e0cd507","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"8e8c318e_09d6d052","in_reply_to":"b5ce5cd0_6b89b04b","updated":"2026-06-11 07:18:30.000000000","message":"\u003e Yes also USB should be part of this wide reorg, and also the various commands to select between USB and TCP in cmsis-dap driver, and the command adapter usb location.\n\nAgreed.\n\n\u003e It should be better defining the overall strategy before coding it. I don\u0027t know how long it will take and if v1.0.0 can wait for it.\n\nI think the current codebase is a good starting point, but let\u0027s not wait for it and push the release back any further.\n\n\u003e It would be a mess to have all them in the same command, because something generic should be in the interface.cfg, something specific should go on the command line.\n\u003e [...]\n\nThanks for the input! I\u0027ll go through all the drivers and commands and put together a proposal that (hopefully) covers everything.\n\n\u003e Are you ok if I merge https://review.openocd.org/c/9529 right now and later you rebase https://review.openocd.org/c/9712 from this series on the new master?\n\nSure, please merge it.","commit_id":"f94a28d2649ef89105a56940581995074aff03bb"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"c1bb7d1619430ae2b50f98e9440e65cb6701a83d","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"b5ce5cd0_6b89b04b","in_reply_to":"e5faff89_bfd0cbfe","updated":"2026-06-10 13:52:14.000000000","message":"Also GDB defines some prefix, even if `help target remote` does not list them.\nThey are \"tcp:\", \"tcp4:\", \"tcp6:\", \"udp:\", \"udp4:\", \"udp6:\". See\nhttps://sourceware.org/git/?p\u003dbinutils-gdb.git;a\u003dblob;f\u003dgdbsupport/netstuff.cc;h\u003dc63bafbdac4aaee681593c64f1a9cbf7e7ceff8e;hb\u003dHEAD#l131\n\nYes also USB should be part of this wide reorg, and also the various commands to select between USB and TCP in cmsis-dap driver, and the command `adapter usb location`.\n\nIt should be better defining the overall strategy before coding it. I don\u0027t know how long it will take and if v1.0.0 can wait for it.\n\nIn OpenOCD we have auto selection, e.g.:\n- several USB VID/PID and we look for the first matching device\n- cmsis-dap check first for USB bulk, then for USB HID (at last for TCP)\n\nand then we have commands to restrict the selections\n- override for a specific USB VID/PID\n- check for USB serial or USB location or product_name\n- command `cmsis-dap backend [auto | usb_bulk | hid | tcp]`\n- ...\n\nIt would be a mess to have all them in the same command, because something generic should be in the interface.cfg, something specific should go on the command line.\n\nWould be easier if we convert these config options in a Tcl array or a dict?\nThe command `adapter driver xxx` just creates an array or a dict with the default options, then user can change them.\nFor `adapter driver st-link` it would create:\n```\nset adapter\n{\n  driver     st-link\n  vid-pid    {0x0483 0x3744 0x0483 0x3748 ...}\n  backend    usb\n}\n```\nand used can add on command line\n`-c \u0027set adapter(serial) 0123456789\u0027`\nor use a single VID/PID\n`-c \u0027set adapter(vid-pid) {0x0483 0x3744}\u0027`\nor, more complex, add a new VID/PID not in the list\n`-c \u0027set adapter(vid-pid) \"[array get adapter(vid-pid)] {0x0483 0x1234}\"\u0027`\nOne issue of this approach is that the values get checked only during the adapter init phase, not when the value is set. But this can be mitigated with a proper output describing the error and dumping unsupported dict keys.\nEventually, to help the user, we could keep some Tcl proc to wrap the array/dict syntax:\n```\nproc \"adapter serial\" {serial}\n{\n  set adapter(serial) $serial\n}\n```\n\nOff-topic.\nAre you ok if I merge https://review.openocd.org/c/9529 right now and later you rebase https://review.openocd.org/c/9712 from this series on the new master?","commit_id":"f94a28d2649ef89105a56940581995074aff03bb"}],"doc/openocd.texi":[{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"cf84309ac5f7c26cdbaf9e77d34d8871b0160cb6","unresolved":true,"context_lines":[{"line_number":2519,"context_line":"@end example"},{"line_number":2520,"context_line":""},{"line_number":2521,"context_line":"Because square brackets (@code{[]}) are used for command substitution in Tcl,"},{"line_number":2522,"context_line":"you must escape them when you specify an IPv6 address:"},{"line_number":2523,"context_line":""},{"line_number":2524,"context_line":"@example"},{"line_number":2525,"context_line":"adapter remote \\[::1\\]:4567"}],"source_content_type":"text/x-texinfo","patch_set":1,"id":"6698ffdd_7b0e3c94","line":2522,"updated":"2026-06-08 16:33:26.000000000","message":"Tcl does not substitute text within `{}`.\n`you must escape them or put them in curly brackets when you specify an IPv6 address:`","commit_id":"f94a28d2649ef89105a56940581995074aff03bb"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"cf84309ac5f7c26cdbaf9e77d34d8871b0160cb6","unresolved":true,"context_lines":[{"line_number":2522,"context_line":"you must escape them when you specify an IPv6 address:"},{"line_number":2523,"context_line":""},{"line_number":2524,"context_line":"@example"},{"line_number":2525,"context_line":"adapter remote \\[::1\\]:4567"},{"line_number":2526,"context_line":"@end example"},{"line_number":2527,"context_line":""},{"line_number":2528,"context_line":"For hostnames and IP addresses, the port number can be omitted to use the"}],"source_content_type":"text/x-texinfo","patch_set":1,"id":"316dcbf1_ab646cb9","line":2525,"updated":"2026-06-08 16:33:26.000000000","message":"add:\n`adapter remote {[::1]:4567}`","commit_id":"f94a28d2649ef89105a56940581995074aff03bb"}],"src/jtag/adapter.c":[{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"cf84309ac5f7c26cdbaf9e77d34d8871b0160cb6","unresolved":true,"context_lines":[{"line_number":515,"context_line":""},{"line_number":516,"context_line":"\tfree(adapter_config.remote.address);"},{"line_number":517,"context_line":"\tadapter_config.remote.address \u003d NULL;"},{"line_number":518,"context_line":"\tstruct adapter_remote *remote \u003d \u0026adapter_config.remote;"},{"line_number":519,"context_line":""},{"line_number":520,"context_line":"\tint retval \u003d parse_remote_address(CMD_ARGV[0], remote);"},{"line_number":521,"context_line":"\tif (retval !\u003d ERROR_OK) {"}],"source_content_type":"text/x-csrc","patch_set":1,"id":"c729a273_a2149990","line":518,"updated":"2026-06-08 16:33:26.000000000","message":"Nitty picky ... running a second time `adapter remote` with invalid argument will erase the previous values.\nMaybe better working on a local struct:\n\n```\nstruct adapter_remote tmp \u003d {0};\nint retval \u003d parse_remote_address(CMD_ARGV[0], \u0026tmp);\nif (retval !\u003d ERROR_OK) {\n\tcommand_print(CMD, \"invalid remote address\");\n\treturn ERROR_COMMAND_ARGUMENT_INVALID;\n}\nfree(adapter_config.remote.address);\nadapter_config.remote \u003d tmp;\nreturn ERROR_OK;\n```","commit_id":"f94a28d2649ef89105a56940581995074aff03bb"}]}