From: Shuah Khan <skhan@linuxfoundation.org>
To: Jason Colapietro <jasoncola1@gmail.com>,
shuah@kernel.org, valentina.manea.m@gmail.com
Cc: greg@kroah.com, i@zenithal.me, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH v7] usbip: make remote list honor parsable output
Date: Thu, 1 Oct 2026 06:53:52 -0600 [thread overview]
Message-ID: <05047d41-499a-4e96-ac64-bebdc0b330c9@linuxfoundation.org> (raw)
In-Reply-To: <1557ed70-d2da-424c-8ba6-10c898bbb81c@linuxfoundation.org>
On 10/1/26 06:49, Shuah Khan wrote:
> On 9/26/26 22:00, Jason Colapietro wrote:
>> Hi Shuah and all,
>>
>> The exact v7 patch has now been built and tested with a native Linux
>> USB/IP stack.
>>
>> Test setup: Alpine Linux 3.23.4 on aarch64, kernel 6.18.53-0-lts,
>> usbip-utils 2.0. A QEMU USB mass-storage device (46f4:0001, busid 2-1)
>> was bound to usbip-host and exported by usbipd. The client connected
>> to 127.0.0.1:3240.
>>
>> With the unpatched client, "usbip list -p -r 127.0.0.1" still printed
>> the human-readable "Exportable USB devices" report, reproducing the
>> bug. With the v7 client, the same command returned:
>>
>> busid=2-1#usbid=46f4:0001#
>>
>> "usbip list -r 127.0.0.1" retained its human-readable output,
>> including the device path and interface details. After unbinding the
>> device, the parsable command exited successfully with zero bytes on
>> stdout; rebinding restored the record.
>>
>> I also attached busid 2-1 through the v7 client. "usbip port" showed
>> it imported through vhci_hcd at port 08, and lsusb showed the device
>> on both the original and virtual host buses. Detach succeeded, leaving
>> no imported port. The build, list, attach, and detach commands all
>> exited successfully.
>>
>> This was one Linux VM with an emulated USB device and TCP loopback. I
>> have not tested physical USB hardware or two separate machines. The
>> existing option-order behavior is unchanged: -p must precede -r.
>
> Please test this with two systems hots running on one and client on the
> other. Send me before and after output that shows the bug and that it is
> fixed by your change.
Another thing. This needs to be reproduced and tested on the latest kenel,
Linux 7.3-rc5
thanks,
-- Shuah
next prev parent reply other threads:[~2026-10-01 12:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-07 8:36 [PATCH v7] usbip: make remote list honor parsable output Jason Colapietro
2026-09-14 17:43 ` Jason Colapietro
2026-09-23 8:44 ` Shuah Khan
2026-09-27 4:00 ` Jason Colapietro
2026-10-01 12:49 ` Shuah Khan
2026-10-01 12:53 ` Shuah Khan [this message]
2026-10-01 16:13 ` jasoncola1
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=05047d41-499a-4e96-ac64-bebdc0b330c9@linuxfoundation.org \
--to=skhan@linuxfoundation.org \
--cc=greg@kroah.com \
--cc=i@zenithal.me \
--cc=jasoncola1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=valentina.manea.m@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.