From: Edward Cree <ecree.xilinx@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>,
Brian Norris <briannorris@chromium.org>
Cc: Kalle Valo <kvalo@codeaurora.org>,
netdev@vger.kernel.org,
linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: pull-request: wireless-drivers-next-2020-12-03
Date: Tue, 8 Dec 2020 15:01:39 +0000 [thread overview]
Message-ID: <bd5f9ded-e575-705b-a56b-a92f7765235f@gmail.com> (raw)
In-Reply-To: <20201207121029.77d48f2c@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com>
On 07/12/2020 20:10, Jakub Kicinski wrote:
> On Mon, 7 Dec 2020 11:35:53 -0800 Brian Norris wrote:
>> Is there some reference for this rule (e.g., dictate from on high; or
>> some explanation of reasons)? Or limitations on it?
>
> TBH its one of those "widely accepted truth" in networking which was
> probably discussed before I started compiling kernels so I don't know
> the full background.
My understanding is that it's because users can have them in their
modprobe.conf, which causes breakage if an update removes the param.
I think the module insert fails if there are unrecognised parameters
there.
>> this sounds like one could never drop a module parameter, or remove
>> obsolete features.
Not far from the truth. If you stop the network from coming up on
boot you can really ruin a sysadmin's day :-/
But usually you can remove the feature, and leave the modparam not
connected to anything, except maybe a deprecation warning printk if
it's set to something other than the default.
-ed
next prev parent reply other threads:[~2020-12-08 15:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-03 18:57 pull-request: wireless-drivers-next-2020-12-03 Kalle Valo
2020-12-04 19:17 ` Jakub Kicinski
2020-12-07 10:40 ` Kalle Valo
2020-12-07 19:35 ` Brian Norris
2020-12-07 20:10 ` Jakub Kicinski
2020-12-08 7:14 ` Emmanuel Grumbach
2020-12-08 15:01 ` Edward Cree [this message]
2020-12-09 2:23 ` Brian Norris
2020-12-09 2:52 ` Brian Norris
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=bd5f9ded-e575-705b-a56b-a92f7765235f@gmail.com \
--to=ecree.xilinx@gmail.com \
--cc=briannorris@chromium.org \
--cc=kuba@kernel.org \
--cc=kvalo@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.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).