Wed, Jun 08, 2022 at 04:58:27PM CEST, kuba@xxxxxxxxxx wrote: >On Wed, 8 Jun 2022 10:27:15 +0200 Jiri Pirko wrote: >> Wed, Jun 08, 2022 at 06:39:55AM CEST, kuba@xxxxxxxxxx wrote: >> >Netdev reference helpers have a dev_ prefix for historic >> >reasons. Renaming the old helpers would be too much churn >> >> Hmm, I think it would be great to eventually rename the rest too in >> order to maintain unique prefix for netdev things. Why do you think the >> "churn" would be an issue? > >Felt like we're better of moving everyone to the new tracking helpers >than doing just a pure rename. But I'm not opposed to a pure rename. > >> >diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c >> >index 817577e713d7..815738c0e067 100644 >> >--- a/drivers/net/macsec.c >> >+++ b/drivers/net/macsec.c >> >@@ -3462,7 +3462,7 @@ static int macsec_dev_init(struct net_device *dev) >> > memcpy(dev->broadcast, real_dev->broadcast, dev->addr_len); >> > >> > /* Get macsec's reference to real_dev */ >> >- dev_hold_track(real_dev, &macsec->dev_tracker, GFP_KERNEL); >> >+ netdev_hold(real_dev, &macsec->dev_tracker, GFP_KERNEL); >> >> So we later decide to rename dev_hold() to obey the netdev_*() naming >> scheme, we would have collision. > >dev_hold() should not be used in new code, we should use tracking >everywhere. Given that we can name the old helpers __netdev_hold(). > >> Also, seems to me odd to have: >> OLDPREFIX_x() >> and >> NEWPREFIX_x() >> to be different functions. >> >> For the sake of not making naming mess, could we rather have: >> netdev_hold_track() >> or >> netdev_hold_tr() if the prior is too long >> ? > >See above, one day non-track version should be removed. >IMO to encourage use of the track-capable API we could keep their names >short and call the legacy functions __netdev_hold() as I mentioned or >maybe netdev_hold_notrack(). Okay, that makes sense.
