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-next>] [day] [month] [year] [list]
Message-ID: <87sfq8qqus.fsf@tynnyri.adurom.net>
Date:   Wed, 20 Apr 2022 08:13:47 +0300
From:   Kalle Valo <kvalo@...nel.org>
To:     Jani Nikula <jani.nikula@...el.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, intel-gfx@...ts.freedesktop.org,
        dri-devel@...ts.freedesktop.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Lucas De Marchi <lucas.demarchi@...el.com>,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 0/1] add support for enum module parameters

+ linux-wireless, netdev

Jani Nikula <jani.nikula@...el.com> writes:

> On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
>> On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
>>> Hey, I've sent this before, ages ago, but haven't really followed
>>> through with it. I still think it would be useful for many scenarios
>>> where a plain number is a clumsy interface for a module param.
>>> 
>>> Thoughts?
>>
>> We should not be adding new module parameters anyway (they operate on
>> code, not data/devices), so what would this be used for?
>
> I think it's just easier to use names than random values, and this also
> gives you range check on the input.
>
> I also keep telling people not to add new module parameters, but it's
> not like they're going away anytime soon.
>
> If there's a solution to being able to pass device specific debug
> parameters at probe time, I'm all ears. At least i915 has a bunch of
> things which can't really be changed after probe, when debugfs for the
> device is around. Module parameters aren't ideal, but debugfs doesn't
> work for this.

Wireless drivers would also desperately need to pass device specific
parameters at (or before) probe time. And not only debug parameters but
also configuration parameters, for example firmware memory allocations
schemes (optimise for features vs number of clients etc) and whatnot.

Any ideas how to implement that? Is there any prior work for anything
like this? This is pretty hard limiting usability of upstream wireless
drivers and I really want to find a proper solution.


-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ