[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20170508.152135.1200615918260312115.davem@davemloft.net>
Date: Mon, 08 May 2017 15:21:35 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: stephen@...workplumber.org
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH RFC] net: Fix inconsistent teardown and release of
private netdev state.
From: Stephen Hemminger <stephen@...workplumber.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.
Powered by blists - more mailing lists