Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Matt Domsch]

On Mon, Mar 04, 2013 at 10:03:01AM -0600, Andy Gospodarek wrote:
> On Mon, Mar 04, 2013 at 09:01:35AM -0600, Matt Domsch wrote:
> > On Mon, Mar 04, 2013 at 08:44:55AM -0600, Domsch, Matt wrote:
> > > The challenge here is that because struct netdev is initialized to all
> > > zeros, code that consumes dev_id can't tell the difference between a
> > > driver _setting_ the value to 0 because it has 2 ports 0 and 1, and a
> > > default (unset) value of 0.  I think the only solution here is to make
> > > sure the kernel drivers, if they need to set it, always set this
> > > non-zero, so udev, seeing a non-zero value, knows it's a valid value
> > > to use.
> > 
> > These seem to be the 4 drivers currently setting dev_id:
> > 
> > drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:             adap->port[i]->dev_id = j;
> > drivers/net/ethernet/freescale/fec.c:   fep->dev_id = dev_id++;
> 
> Look up a few lines:
> 
>         /* setup board info structure */
>         fep = netdev_priv(ndev);
> 
> fep is not a pointer to the net_device, but to the private device
> structure.  This is why I didn't include it in the list.

Good catch.
 
> > drivers/net/ethernet/mellanox/mlx4/en_netdev.c: dev->dev_id =  port - 1;
> > drivers/net/ethernet/sfc/siena.c:       efx->net_dev->dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1;
> > 
> > of these, both the mlx4 and siena drivers set them starting at 0.  I
> > think the fec driver might be doing so as well, but it's not as
> > obvious.  I'm pretty sure cxgb4 starts numbering at 1 just from
> > reading the code.  So, as-is in the 3.9rc1 kernel, I wouldn't be
> > comfortable relying on the value of dev_id.
> 
> I agree it looks like some cleanup is needed due to the inconsistency.
> 
> This is still only an issue when a single function supports multiple
> ethernet devices, right?

I believe so, yes.

-- 
Matt Domsch
Technology Strategist
Dell | Office of the CTO