Messages in this thread | | | Date | Sun, 13 Nov 2022 21:03:52 +0100 | Subject | Re: [PATCH] net: dsa: use NET_NAME_PREDICTABLE for user ports with name given in DT | From | Rasmus Villemoes <> |
| |
On 11/11/2022 18.10, Andrew Lunn wrote: >> diff --git a/net/dsa/slave.c b/net/dsa/slave.c >> index a9fde48cffd4..dfefcc4a9ccf 100644 >> --- a/net/dsa/slave.c >> +++ b/net/dsa/slave.c >> @@ -2374,16 +2374,25 @@ int dsa_slave_create(struct dsa_port *port) >> { >> struct net_device *master = dsa_port_to_master(port); >> struct dsa_switch *ds = port->ds; >> - const char *name = port->name; >> struct net_device *slave_dev; >> struct dsa_slave_priv *p; >> + const char *name; >> + int assign_type; >> int ret; >> >> if (!ds->num_tx_queues) >> ds->num_tx_queues = 1; >> >> + if (port->name) { >> + name = port->name; >> + assign_type = NET_NAME_PREDICTABLE; >> + } else { >> + name = "eth%d"; >> + assign_type = NET_NAME_UNKNOWN; >> + } > > I know it is a change in behaviour, but it seems like NET_NAME_ENUM > should be used, not NET_NAME_UNKNOWN. alloc_etherdev_mqs() uses > NET_NAME_ENUM.
I don't really have any strong opinion on the case where we fall back to eth%d, as its not relevant to any board I've worked on.
> https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/netdevice.h#L42 > says that NET_NAME_UNKNOWN does not get passed to user space, but i > assume NET_NAME_ENUM does. So maybe changing it would be an ABI > change?
Well, the name_assign_type ABI is kind of silly. I mean, userspace knows that when one gets EINVAL trying to read the value, that really means that the value is NET_NAME_UNKNOWN. But I won't propose changing that.
However, what I do propose here is obviously already an ABI change; I _want_ to expose more proper information in the case where the port has a label, and just kept the NET_NAME_UNKNOWN for the eth%d case to make the minimal change. But if people want to change that to NET_NAME_ENUM while we're here, I can certainly do that. I can't think of any real scenario where NET_NAME_ENUM would be treated differently than NET_NAME_UNKNOWN - in both cases, userspace don't know that the name can be trusted to be predictable.
Rasmus
| |