Re: [PATCH] net: usbnet: allow overriding of default USB interface naming

[Jonathan Davies <jonathan.davies@nutanix.com>]

On 14/06/2021 14:51, Greg KH wrote:
> On Mon, Jun 14, 2021 at 11:58:57AM +0100, Jonathan Davies wrote:
>> On 14/06/2021 10:43, Greg KH wrote:
>>> On Mon, Jun 14, 2021 at 10:32:05AM +0100, Jonathan Davies wrote:
>>>> On 12/06/2021 08:01, Greg KH wrote:
>>>>> On Fri, Jun 11, 2021 at 03:23:39PM +0000, Jonathan Davies wrote:
>>>>>> When the predictable device naming scheme for NICs is not in use, it is
>>>>>> common for there to be udev rules to rename interfaces to names with
>>>>>> prefix "eth".
>>>>>>
>>>>>> Since the timing at which USB NICs are discovered is unpredictable, it
>>>>>> can be interfere with udev's attempt to rename another interface to
>>>>>> "eth0" if a freshly discovered USB interface is initially given the name
>>>>>> "eth0".
>>>>>>
>>>>>> Hence it is useful to be able to override the default name. A new usbnet
>>>>>> module parameter allows this to be configured.
>>>>>>
>>>>>> Signed-off-by: Jonathan Davies <jonathan.davies@nutanix.com>
>>>>>> Suggested-by: Prashanth Sreenivasa <prashanth.sreenivasa@nutanix.com>
>>>>>> ---
>>>>>>     drivers/net/usb/usbnet.c | 13 ++++++++++---
>>>>>>     1 file changed, 10 insertions(+), 3 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
>>>>>> index ecf6284..55f6230 100644
>>>>>> --- a/drivers/net/usb/usbnet.c
>>>>>> +++ b/drivers/net/usb/usbnet.c
>>>>>> @@ -72,6 +72,13 @@ static int msg_level = -1;
>>>>>>     module_param (msg_level, int, 0);
>>>>>>     MODULE_PARM_DESC (msg_level, "Override default message level");
>>>>>> +#define DEFAULT_ETH_DEV_NAME "eth%d"
>>>>>> +
>>>>>> +static char *eth_device_name = DEFAULT_ETH_DEV_NAME;
>>>>>> +module_param(eth_device_name, charp, 0644);
>>>>>> +MODULE_PARM_DESC(eth_device_name, "Device name pattern for Ethernet devices"
>>>>>> +				  " (default: \"" DEFAULT_ETH_DEV_NAME "\")");
>>>>>
>>>>> This is not the 1990's, please do not add new module parameters as they
>>>>> are on a global driver level, and not on a device level.
>>>>
>>>> The initial name is set at probe-time, so the device doesn't exist yet. So I
>>>> felt like it was a choice between either changing the hard-coded "eth%d"
>>>> string or providing a driver-level module parameter. Is there a better
>>>> alternative?
>>>
>>> This has always been this way, why is this suddenly an issue?  What
>>> changed to cause the way we can name these devices after they have been
>>> found like we have been for the past decade+?
>>
>> The thing that changed for me was that system-udevd does *not* have the
>> backoff and retry logic that traditional versions of udev had.
>>
>> Compare implementations of rename_netif in
>> https://git.kernel.org/pub/scm/linux/hotplug/udev.git/tree/src/udev-event.c 
>> (traditional udev, which handles collisions) and
>> https://github.com/systemd/systemd/blob/main/src/udev/udev-event.c 
>> (systemd-udevd, which does not handle collisions).
> 
> Then submit a change to add the logic back.  This looks like a userspace
> tool breaking existing setups, so please take it up with the developers
> of that tool.  The kernel has not changed or "broken" anything here.

(I didn't mean to imply that the kernel was to blame, merely that a 
kernel change could help make things tidier.)

>> I think this logic was removed under the assumption that users of
>> systemd-udevd would also use the predictable device naming scheme, meaning
>> renames are guaranteed to not collide with devices being probed.
> 
> Why are you not using the predictable device naming scheme?  If you have
> multiple network devices in the system, it seems like that is a good
> idea to follow as the developers added that for a reason.

Sadly in my case this isn't possible for reasons beyond my control. I'd 
like to move things in that direction but in the meantime thought this 
workaround could have been helpful for others who find themselves in the 
same position as me.

Thanks for all the input.

Jonathan