netdev - Re: [PATCH] staging: rtlwifi: Improve debugging by using debugfs

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] [day] [month] [year] [list]

Date:   Fri, 25 Aug 2017 15:00:22 -0700
From:   Alexander Duyck <alexander.duyck@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Larry Finger <Larry.Finger@...inger.net>,
        gregkh@...uxfoundation.org, Netdev <netdev@...r.kernel.org>,
        devel@...verdev.osuosl.org, Ping-Ke Shih <pkshih@...ltek.com>,
        Yan-Hsuan Chuang <yhchuang@...ltek.com>,
        Birming Chiu <birming@...ltek.com>,
        Shaofu <shaofu@...ltek.com>, Steven Ting <steventing@...ltek.com>
Subject: Re: [PATCH] staging: rtlwifi: Improve debugging by using debugfs

Fri, Aug 25, 2017 at 7:16 AM, Andrew Lunn <andrew@...n.ch> wrote:
> On Fri, Aug 25, 2017 at 08:47:00AM -0500, Larry Finger wrote:
>> On 08/24/2017 08:54 PM, Andrew Lunn wrote:
>> >netdev frowns upon debugfs. You should try to keep this altogether,
>> >making it easy to throw away before the driver is moved out of
>> >staging.
>> >
>> >You might want to look at ethtool -d. That will be accepted.
>>
>> Andrew,
>>
>> What is the problem with debugfs?
>
> You should probably look back in the discussions on the netdev
> mailling list. But basically, anything you want to export should
> follow generic well defined interface, which can be used by other
> drivers. debugfs tends to be a mess, a wild west, each driver doing
> its own thing, not standardisation. It is O.K. for your own
> development work, you can have your own out of tree patches adding in
> debugfs, but such patches are unlikely to be accepted into mainline.
> David has threatened to simply rip out all debugfs code from all
> network drivers. There is push back on adding any new debugfs code,
> and some driver writers have taken out debugfs code in their own
> drivers, often replacing it with something generic all drivers can
> use.

I think the bigger issue is that many people end up using debugfs to
try and configure things, or they create redundant functionality with
existing interfaces which is generally frowned upon. So generally it
is okay for things like peeking into driver state machines, or as a
means to dump descriptor rings, but not okay for using to program
filters, write registers, change the device state, or collect generic
statistics.