Re: [PATCH v6 0/5] tools/usbip: Patch set summary

[Lars Gunnarsson <gunnarsson.lars@gmail.com>]

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