From: Stephen Hemminger <step...@networkplumber.org> Date: Mon, 8 May 2017 12:13:59 -0700
> Thanks for addressing a confusing and messy semantic. If you merge > this then it would be good to update the documentation in > Doucmentation/networking to describe how drivers are supposed to > behave. Will do. > An alternative and more difficult way of addressing the problem would > be to rework the drivers that define destructors to work with the simpler > model used by all the other drivers. What makes these drivers special, > and can they be fixed instead. Probably this won't work and would be too > much effort on lots of little used devices. The biggest problem is that we have two models of teardown... well actually the issue is more about resources allocated at probe time. For many software devices, instances come from ->newlink() or other config requests, so they go "register the device" and then forget about it, leaving it to the registered callbacks to cleanup. But things are different for most hardware devices. They allocate resources on probe, and therefore absolutely cannot let register_netdevice(), or the callbacks, release those resources nor perform the free_netdev(). So what a lot of drivers do is, in their driver ->remove() method, unregister the device, release the probe time resources, then do the free_netdev() by hand. So as you say, these interfaces and their behavior evolved over time in response to need.