netdev - Re: pull-request: wireless-drivers-next-2020-12-03

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+ASDXNT+uKLLhTV0Nr-wxGkM16_OkedUyoEwx5FgV3ML9SMsQ@mail.gmail.com>
Date:   Mon, 7 Dec 2020 11:35:53 -0800
From:   Brian Norris <briannorris@...omium.org>
To:     Kalle Valo <kvalo@...eaurora.org>, Jakub Kicinski <kuba@...nel.org>
Cc:     "<netdev@...r.kernel.org>" <netdev@...r.kernel.org>,
        linux-wireless <linux-wireless@...r.kernel.org>
Subject: Re: pull-request: wireless-drivers-next-2020-12-03

On Mon, Dec 7, 2020 at 2:42 AM Kalle Valo <kvalo@...eaurora.org> wrote:
> Jakub Kicinski <kuba@...nel.org> writes:
> > On Thu,  3 Dec 2020 18:57:32 +0000 (UTC) Kalle Valo wrote:
> > There's also a patch which looks like it renames a module parameter.
> > Module parameters are considered uAPI.
>
> Ah, I have been actually wondering that if they are part of user space
> API or not, good to know that they are. I'll keep an eye of this in the
> future so that we are not breaking the uAPI with module parameter
> changes.

Is there some reference for this rule (e.g., dictate from on high; or
some explanation of reasons)? Or limitations on it? Because as-is,
this sounds like one could never drop a module parameter, or remove
obsolete features. It also suggests that debug-related knobs (which
can benefit from some amount of flexibility over time) should go
exclusively in debugfs (where ABI guarantees are explicitly not made),
even at the expense of usability (dropping a line into
/etc/modprobe.d/ is hard to beat).

That's not to say I totally disagree with the original claim, but I'm
just interested in knowing precisely what it means.

And to put a precise spin on this: what would this rule say about the following?

http://git.kernel.org/linus/f06021a18fcf8d8a1e79c5e0a8ec4eb2b038e153
iwlwifi: remove lar_disable module parameter

Should that parameter have never been introduced in the first place,
never be removed, or something else? I think I've seen this sort of
pattern before, where features get phased in over time, with module
parameters as either escape hatches or as opt-in mechanisms.
Eventually, they stabilize, and there's no need (or sometimes, it's
actively harmful) to keep the knob around.

Or the one that might (?) be in question here:
fc3ac64a3a28 rtw88: decide lps deep mode from firmware feature.

The original module parameter was useful for enabling new power-saving
features, because the driver didn't yet know which chip(s)/firmware(s)
were stable with which power features. Now, the driver has learned how
to figure out the optimal power settings, so it's dropping the old
param and adding an "escape hatch", in case there are problems.

I'd say this one is a bit more subtle than the lar_disable example,
but I'm still not sure that really qualifies as a "user-visible"
change.

Brian