Re: [PATCH v6] usbip: make remote list honor parsable output

[Shuah Khan <skhan@linuxfoundation.org>]

On 8/22/26 14:38, Jason Colapietro wrote:
> The -p option is accepted in every list mode and `usbip help list`
> documents it as "Parsable list format", but it only ever reached the
> local (-l) and gadget (-d) paths. list_exported_devices() never took
> the flag, so -r ignores it and always prints the human-readable report.
> 
> Both commands below pass -p, and only the local one honors it:
> 
>    $ usbip list -p -l
>    busid=1-2#usbid=1a86:55d4#
>    busid=2-1#usbid=0627:0001#
> 
>    $ usbip list -p -r localhost
>    Exportable USB devices
>    ======================
>     - localhost
>            2-3: ATECH FLASH TECHNOLOGY : Kingston SNA-DC/U (11b0:6298)
>               : /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-3
>               : (Defined at Interface level) (00/00/00)
> 
> `usbip list -r <host>` and `usbip list -p -r <host>` produce
> byte-identical output, so a script has to scrape the decorated report
> instead: the column padding, the " - <host>" banner, the blank line
> between devices and the per-interface lines. That is what the reporter
> hit in bugzilla 219502.
> 
> Use one file-scope flag for the list command and honor it in the remote
> listing path. Emit the same busid and usbid record used for local
> devices while continuing to consume every interface record from the
> server. After the change -r produces the record shape -l already does:
> 
>    $ usbip list -p -r 127.0.0.1
>    busid=1-1#usbid=0781:5583#
>    busid=1-2#usbid=046d:c52b#
> 
> so the obvious loop works against a remote host:
> 
>    for b in $(usbip list -p -r "$host" | sed 's/^busid=//; s/#.*//'); do
>            usbip attach -r "$host" -b "$b"
>    done
> 
> Without -p the remote output is unchanged.
> 
> Fixes: e9837bbb3e69 ("staging: usbip: userspace tools v1.0.0")
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219502
> Assisted-by: LLM
> Signed-off-by: Jason Colapietro <jasoncola1@gmail.com>
> ---
> v5 -> v6:
> - Fold a condensed before/after into the commit message, as Shuah asked
>    for on v2. No code changes; the diff is identical to v5.
> - Restore the Assisted-by tag, in the format required by
>    Documentation/process/coding-assistants.rst. v2 carried it as
>    "Assisted-by: Codex:gpt-5", which predates that document.
> 
> Tooling disclosure, per Documentation/process/generated-content.rst: an
> AI coding assistant was used for the original code change, and in this
> revision to rewrite the commit message so it carries the before/after
> requested on v2. The code is byte-identical to v5. checkpatch.pl
> --strict reports no errors, and the patch applies cleanly with git am
> onto mainline.
> 
> v4 -> v5:
> - Drop Cc: stable@vger.kernel.org. This changes the user-visible output
>    of "usbip list -r -p", so it is not a stable backport candidate.
> 
> v3 -> v4:
> - Make parsable file-scope instead of passing it through list helpers.
> - Drop the option-ordering change to preserve existing behavior.
> 
> Two behaviours I checked beyond the output quoted above:
> 
> - The connection stays in sync. Interface records are still read from
>    the socket in parsable mode, only the printf is suppressed. To confirm
>    that rather than assert it, I had the test server withhold the final
>    4-byte usbip_usb_interface record for 3 seconds: the patched client
>    with -p blocks for the full 3 seconds, so it really is draining every
>    record.
> 
> - With no exported devices, -p prints nothing on stdout ("no exportable
>    devices found on <host>" still goes to stderr), so stdout stays clean.
> 
> Testing disclosure: my checkout is on macOS, so I have not run a native
> USB/IP stack end to end. The output above comes from building the real
> usbip_list.c, usbip_network.c, usbip_common.c and names.c against a stub
> libudev -- the remote path never calls udev, and the stubs abort if
> reached -- and pointing that binary at a small mock usbipd answering
> OP_REQ_DEVLIST with a real OP_REP_DEVLIST payload. The -p -l side is a
> second build with a fake udev backend presenting the same devices. So it
> is the real listing path over a real socket, but not usbip-host or
> usbip-vudc on hardware. I am happy to redo the runs on a Linux box, or
> to wait for someone with a usbip setup to confirm, before this goes in.
> 

Sorry. It is important to test end to end on a Linux machine to verify
patches. I can't accept patches that aren't tested on macOS - it just
doesn't make sense to do so.

thanks,
-- Shuah