On 12/16/21 2:01 PM, Lars Gunnarsson wrote:
On Tue, Dec 14, 2021 at 03:22:57PM -0700, Shuah Khan wrote:
On 12/9/21 2:11 PM, Lars Gunnarsson wrote:
On Mon, Dec 06, 2021 at 01:02:35PM -0700, Shuah Khan wrote:
On 11/30/21 3:22 PM, Lars Gunnarsson wrote:
To forward a remote usb device over usbip the following steps is required:
1. Execute "usbip bind" on remote end.
2. Execute "usbip attach" on local end.
These steps must be perfomed in above order and after usb device is plugged in.
If the usb device is unplugged on the remote end the steps above needs to be
performed again to establish the connection. This patch set implements a feature
to persistently forward devices on a given bus. When using flag "-p|--persistent"
on remot end, the USB device becomes exported when plugged in. When using flag
"-p|--persistent" on local end, the USB device becomes imported when available
on remote end. Thus it is only required to run the usbip command once on each
end, in any order, to persistently forward usb devices on a given bus.
This is sent in five separate patches:
tools/usbip: update protocol documentation
tools/usbip: update manual pages
tools/usbip: add usb event monitor into libusbip
tools/usbip: export USB devices on a given bus persistently
tools/usbip: import USB devices on a given bus persistently
When -p is used, the command stays in foreground. This is a very
different use model compared to current model. In addition, once
persistent flag is set on a bus, all devices even the ones that
are inserted in the future get exported. What happens if one of
the devices shouldn't be exported?
Yes it's conceptually more like exporting/importing the physical usb port,
rather than exporting/importing a device plugged into the usb port. Using flag
"-p" on both ends will behave like a "virtual" usb hub, a device plugged in on
the server (on a chosen bus) will automatically be available on the client.
Using flag "-p" has no dependency on the other end though. Using "-p" on one end
doesn't enforce usage on the other end. It is only for exporting and importing
devices automatically when they become available.
There might be better choices than naming flag to "persistent" for easily
communicate this concept. Would "port" be more intuitive?
"usbip attach --port 3-3.1" and "usbip bind --port 3-3.1"
Terminology isn't what I am concerned about. My concern is the idea of
automatically making devices available for export at bus level.
There are several conditions to be thought through:
- What happens if if the command that is running on the foreground
is killed on either end?
If "attach" cmd gets killed (client side) it will stop the foreground
monitoring. The device will still remain imported if user exit at imported state.
The user then needs to manually unimport the device with "detach".
If "bind" cmd gets killed (server side) it will stop the foreground monitoring.
The device will still remain exported if exit at exported state. The user then
needs to manually unexport the device with "unbind".
My concern is the persistence nature of these exports/imports through
reboots. I have to give it some though on how this can be implemented
addressing my concerns.
Can you elaborate on your thoughts about "the persistence nature of these exports/imports through reboots"?
reboot as in exit from foreground and run the command again?
Sorry for the delay in responding.
I have been thinking about this more. I am not convinced that
supporting these use-cases requires usbip changes.
Can we not accomplish the same via scripts/crontab? Monitor if
a bound device is removed and rebind. Do the same on the client
side?
Have you explored if this can be done with existing tools and
a shell script and make use of crontab?
thanks,
-- Shuah
