)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"f60dbba5ed1f37e49501fbba829b63603e11690b","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"fc229648_18c30d2d","updated":"2025-10-14 09:57:39.000000000","message":"Yes, I also noticed this inconsistency when added doc patch.\nThe question is if `smp` command wouldn\u0027t be simpler and better without an architecture prefix. From user point of view, the command is identical on all architectures where is supported, so I see no point in forcing the architecture prefix.\nWhat do you think?","commit_id":"aa7f9fd53e088e04cdabba8c97eedcb43556dbe9"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"17f4e2d05e8c79df7fd0e20f53a1edce411db1f7","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"83d79457_90ab1052","in_reply_to":"369b46e1_f3f8e8f2","updated":"2025-10-21 06:47:52.000000000","message":"\u003e By the way, what should we do with this series?\n\u003e But I\u0027ve not seen new reports on testing this series\n\nI responded in\n8893: target: riscv: Sync with the RISC-V fork | https://review.openocd.org/c/openocd/+/8893\nto notify most of involved developers.","commit_id":"aa7f9fd53e088e04cdabba8c97eedcb43556dbe9"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"cbfbc88b23cbb43f5e534a6d76c8a6285411e656","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"369b46e1_f3f8e8f2","in_reply_to":"39c04eca_de9b88a3","updated":"2025-10-18 07:51:05.000000000","message":"I think we can keep 9133 as is. It respects the sequence of changes in this series.\n\nBy the way, what should we do with this series?\nApart possibly reverting my changes in the commit message 9127 9141 9143 9144, anything else we are waiting for?\nBut I\u0027ve not seen new reports on testing this series","commit_id":"aa7f9fd53e088e04cdabba8c97eedcb43556dbe9"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"506675164c24db4095ce5ccc1ddb0e803923d8f3","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"39c04eca_de9b88a3","in_reply_to":"82aa565d_586382e2","updated":"2025-10-15 07:40:17.000000000","message":"Okay then. The commands are very rarely used (I found one `cortex_a smp on/off` in tcl/target/u8500.cfg and no added usages in riscv-collab fork), so your plan seems reasonable.\n\nShouldn\u0027t I remove these openocd.texi fixes from\n9133: doc: riscv: minor fixes in openocd.texi | https://review.openocd.org/c/openocd/+/9133\nas it gets reverted in this patch?","commit_id":"aa7f9fd53e088e04cdabba8c97eedcb43556dbe9"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"bc1835c145f94cfa001bdfd348eb5e696fa576bd","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"fa54c089_e5adc736","in_reply_to":"83d79457_90ab1052","updated":"2025-10-21 06:48:38.000000000","message":"Done","commit_id":"aa7f9fd53e088e04cdabba8c97eedcb43556dbe9"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"0c9fb14fd2a0655d8d2cf8f6ad383a0f29e1f74d","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"82aa565d_586382e2","in_reply_to":"fc229648_18c30d2d","updated":"2025-10-14 12:15:26.000000000","message":"Yes, we could change all the other implementations, not a big deal.\nThis patch is just the minimum change for consistency.\n\nBut for after v1.0.0 I\u0027m preparing for reworking the SMP implementation.\nWe have old crusted code pre-hwthread, plus the current hwthread that prevents using another RTOS on top of it. Zephyr, for example, allows SMP cores, but in OpenOCD we cannot have both zephyr and hwthread.\n\nMy idea is to add a \u0027virtual\u0027 target type \u0027smp\u0027 that replaces all this stuff.\nOther targets should be added/removed to the list of \u0027real\u0027 targets in the \u0027smp\u0027 target. And we could even have multiple independent \u0027smp\u0027 nodes in a single OpenOCD session.\nThe RTOS (e.g. zephyr) should be added to the \u0027smp\u0027 node.\n\nWhat requires more work is:\n- make possible to add/remove \u0027smp\u0027 target after \u0027init\u0027;\n- make GDB port and server modifiable at runtime (if no GDB is attached). This to handle add/remove targets to \u0027smp\u0027 nodes and consequently closing/opening their private GDB port.\n\nSo, the question is if we want to change the \u0027smp\u0027 syntax now (handling deprecated commands) and change it again in v1.0.0, or we temporarily stick on this old syntax.","commit_id":"aa7f9fd53e088e04cdabba8c97eedcb43556dbe9"}]}