public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Shuah Khan <skhan@linuxfoundation.org>
To: Zongmin Zhou <min_halo@163.com>
Cc: i@zenithal.me, linux-kernel@vger.kernel.org,
	linux-usb@vger.kernel.org, valentina.manea.m@gmail.com,
	Zongmin Zhou <zhouzongmin@kylinos.cn>,
	Greg KH <gregkh@linuxfoundation.org>,
	Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH v2] usbip: tools: Add usbip host driver availability check
Date: Mon, 30 Mar 2026 10:44:33 -0600	[thread overview]
Message-ID: <3ff00e2e-1c45-45be-a65c-16da9b2ae5a5@linuxfoundation.org> (raw)
In-Reply-To: <1667ddf5-e36c-4cba-87b4-9cd3d34032e1@163.com>

On 3/29/26 21:10, Zongmin Zhou wrote:
> 
> On 2026/3/28 02:29, Shuah Khan wrote:
>> On 3/27/26 11:51, Shuah Khan wrote:
>>> On 3/27/26 02:39, Zongmin Zhou wrote:
>>>>
>>>> On 2026/3/27 02:43, Shuah Khan wrote:
>>>>> On 3/26/26 02:43, Greg KH wrote:
>>>
>>> [removed text]
>>>
>>>>>
>>>>> The problem Zongmin is trying fix ish when usbipd starts, it looks for
>>>>> exported if any - if it doesn't find any it assumes there aren't any
>>>>> exported and doesn't detect that usbip_host driver isn't loaded.
>>>>>
>>>>> refresh_exported_devices() doesn't have the logic and it shouldn't
>>>>> include that logic because this hook is called periodically to
>>>>> refresh the list of exported devices. Starting usbipd and loading
>>>>> the driver are distinct steps and without any dependencies.
>>>>>
>>>>> This patch he is trying to add that detection so a message can be printed
>>>>> to say "load the driver".
>>>>>
>>>>> A message can be added easily to cover two cases:
>>>>>
>>>>> 1. usbip_host driver isn't loaded
>>>>> 2. There are no exported devices.
>>>>>
>>>>> refresh_exported_devices() will not find any devices in both
>>>>> of the above scenarios. It isn't an error if it can't find
>>>>> any exported devices.
>>>>>
>>>>> An informational message when refresh_exported_devices()
>>>>> when it doesn't find any devices could help users.
>>>>>
>>>>> Zongmin,
>>>>>
>>>>> Would adding a message that says
>>>>> "Check if usbip_host driver is loaded or export devices"
>>>>> solve the problem of hard to debug problem you are addressing here?
>>>>>
>>>> Shuah,
>>>>
>>>> Your suggestion makes sense.
>>>> Adding an informational message when no devices are found would be a simple
>>>> and clean solution that helps users debug without being intrusive.
>>>>
>>>> However, I plan to add the info() message in usbip_generic_driver_open() instead of
>>>> refresh_exported_devices(), because:
>>>> - usbip_generic_driver_open() is called only once at initialization.
>>>> - refresh_exported_devices() is called periodically to refresh the exported device list.
>>>
>>> refresh_exported_devices() isn't called periodically - it is called
>>> from usbip_host_driver op: refresh_device_list and it will be called
>>> whenever usbipd (host side) calls it whenever it receives a request from
>>> user-space via process_request()
>>>
>>> For example running "usbip list -l" command will trigger a run of
>>> refresh_exported_devices() via usbip_host_driver op: refresh_device_list
>>>
>>> I don't think it will that noisy to add a message to refresh_exported_devices()
>>> when device list is zero. Currently the logic doesn't detect device list zero.
>>> You have add that condition to print informational message.
>>>
>>>
>>>> - When the server has no exported devices, having zero devices
>>>>    is normal and not worth frequent info messages.
>>>
>>> That is correct. Zero exported devices isn't an error and this could
>>> persist until devices are exported.
>>>
>>>>
>>>> Theoretically, we only need to prompt once at startup. Is my understanding correct?> > I'll also remove the existing error messages like below,
>>>> since they cannot accurately determine whether the driver is loaded:
>>>>
>>>> if (ret)
>>>>      err("please load " USBIP_CORE_MOD_NAME ".ko and "
>>>>          USBIP_HOST_DRV_NAME ".ko!");
>>>
>>> Leave this one alone, because it gets called from a couple of places.
> In usbip_generic_driver_open(), the only path that triggers this message is a failure of udev_new().
> This function fails due to system-level issues like memory exhaustion, not because usbip driver module is missing.
> 
> Furthermore, since refresh_exported_devices() doesn't practically return an error here,
> the message is never seen during actual driver loading failures.
> So I think it’s better to remove this inaccurate hint to avoid confusing the users.
> 
> This is the reason why I previously wanted to remove it.
>>>
>>
>> Better yet, why not change the usbip instead - usbip_list for example.
>> This is the one that prints the device list and the change can be made
>> there when the list is zero to say, "Check if driver is loaded and
>> exported devices"
> I think placing the check/message in refresh_exported_devices() would be more effective.
> This function covers all scenarios where the device list is refreshed, including:
> usbipd startup, usbip list -r, and usbip attach operations.

Right changing refresh_exported_devices() covers all cases. Think about the
following scenarios:

- Where will this message get printed when usbipd is started on the console and in
   background?

- Where will this message get printed when user runs various usbip list commands?

Ideally these commands should tell the user what happened without looking
at daemon logs.

thanks,
-- Shuah

  reply	other threads:[~2026-03-30 16:44 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-03  8:17 [PATCH] usbip: tools: Add usbip host driver availability check Zongmin Zhou
2026-03-10 22:28 ` Shuah Khan
2026-03-12  2:17   ` Zongmin Zhou
2026-03-23 19:17     ` Shuah Khan
2026-03-25  2:26       ` [PATCH v2] " Zongmin Zhou
2026-03-25  8:58         ` Greg KH
2026-03-26  3:10           ` Zongmin Zhou
2026-03-26  8:43             ` Greg KH
2026-03-26 18:43               ` Shuah Khan
2026-03-27  8:39                 ` Zongmin Zhou
2026-03-27 17:51                   ` Shuah Khan
2026-03-27 18:29                     ` Shuah Khan
2026-03-30  3:10                       ` Zongmin Zhou
2026-03-30 16:44                         ` Shuah Khan [this message]
2026-03-31  9:58                           ` [PATCH v3] usbip: tools: add hint when no exported devices are found Zongmin Zhou
2026-04-01  0:27                             ` Shuah Khan
2026-04-01  2:47                               ` Zongmin Zhou
2026-04-01 16:06                                 ` Shuah Khan
2026-04-02  8:32                                   ` [PATCH v4] " Zongmin Zhou
2026-04-06 21:12                                     ` Shuah Khan
2026-04-07  2:34                                       ` Zongmin Zhou
2026-04-09 17:25                                     ` Shuah Khan
2026-03-11 12:13 ` [PATCH] usbip: tools: Add usbip host driver availability check Greg KH
2026-03-12  2:17   ` Zongmin Zhou

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=3ff00e2e-1c45-45be-a65c-16da9b2ae5a5@linuxfoundation.org \
    --to=skhan@linuxfoundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=i@zenithal.me \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=min_halo@163.com \
    --cc=valentina.manea.m@gmail.com \
    --cc=zhouzongmin@kylinos.cn \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox