From: David Miller <davem@davemloft.net>
To: stephen@networkplumber.org
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH RFC] net: Fix inconsistent teardown and release of private netdev state.
Date: Mon, 08 May 2017 15:21:35 -0400 (EDT) [thread overview]
Message-ID: <20170508.152135.1200615918260312115.davem@davemloft.net> (raw)
In-Reply-To: <20170508121359.45e367e5@xeon-e3>
From: Stephen Hemminger <stephen@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.
prev parent reply other threads:[~2017-05-08 19:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-08 16:52 [PATCH RFC] net: Fix inconsistent teardown and release of private netdev state David Miller
2017-05-08 19:13 ` Stephen Hemminger
2017-05-08 19:21 ` David Miller [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170508.152135.1200615918260312115.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).