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? > > > > - What happens when one or more devices are detached? > > > > If user exit from "attach" cmd running in foreground, followed by detaching the > > device manually, it will work as previously. The device will become available on > > the server for importing again. > > > > If user running "attach" cmd in foreground, while executing "detach" manually > > from another terminal or similar, the foreground "attach" command will detect > > the disconnection and re-establish the import. I don't see any use case for > > this, it's just for explaining. > > > > If user running "attach" cmd in foreground, while the remote device becomes > > unexported (or disconnected) it will start polling the usbipd. > > When a device becomes exported on the chosen bus it gets imported immediately. > > > > > - What happens when one or more devices are unbound from > > > the server? > > > > > > Let's walk through these scenarios. > > > > If user exit from "bind" cmd running in foreground, followed by unbind the > > device manually it will work as previous. The usb device will become available > > on the server again. > > > > If user running "bind" cmd in foreground, while executing "unbind" from another > > terminal or similar, the foreground "bind" command will detect the unexport > > and re-establish the export. I don't see any use case for this, it's just for > > explaining. > > > > If user running "bind" cmd in foreground, while the device becomes unexported > > or disconnected it will restart monitoring the busid. When a device becomes > > plugged in on the chosen usb port it gets exported immediately. > > > > One option to consider is to unexport & unimport the device at exit, but this > > comes with the cost of creating a source code dependency between > > bind --> unbind and attach --> detach. > > > > How does this look like in code? > > thanks, > -- Shuah
