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

[Shuah Khan <skhan@linuxfoundation.org>]

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