netdev - RE: [net-next 04/14] i40e: dump VF information in 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <BL2PR07MB2306DEC60F085B88BA230C3A8D1B0@BL2PR07MB2306.namprd07.prod.outlook.com>
Date:   Thu, 20 Apr 2017 13:57:08 +0000
From:   "Mintz, Yuval" <Yuval.Mintz@...ium.com>
To:     Jiri Pirko <jiri@...nulli.us>
CC:     Or Gerlitz <gerlitz.or@...il.com>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        Mitch Williams <mitch.a.williams@...el.com>,
        David Miller <davem@...emloft.net>,
        Linux Netdev List <netdev@...r.kernel.org>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "sassmann@...hat.com" <sassmann@...hat.com>,
        "jogreene@...hat.com" <jogreene@...hat.com>
Subject: RE: [net-next 04/14] i40e: dump VF information in debugfs

> >> > Dump some internal state about VFs through debugfs. This provides
> >> > information not available with 'ip link show'.
> >>
> >> such as?
> >>
> >> donnwantobethedebugfspolice, but still, in the 2-3 times we tried to
> >> push debugfs to MLNX NIC drivers, Dave disallowed that, and lately
> >> the switch team even went further and deleted that portion of the
> >> mlxsw driver -- all to all,  I don't see much point for these type of changes,
> thoughts?
> >
> >Don't want to hikjack your thread, but continuing this topic - Is there
> >some flat-out disapproval for debugfs in net-next now?
> 
> It was mentioned by DaveM on the list multiple times.

> >
> >We're currently internally engaged with adding qed support for register
> >dumps [~equivalents for `ethtool -d' outputs] through debugfs, on
> >behalf of storage drivers [qedi/qedf] lacking the API for doing that.
> 
> That sounds wrong. Either introduce a generic infra to expose the info you
> need or you don't do that.

I agree this surely isn't *our* convention, but for scsi  using debugfs
[or sysfs] is a common practice for debug purposes.

Also, our HW debug capabilities are highly-customable, and I want to
have the ability to configure those on the fly [E.g., dynamically
configuring various HW events to be recorded].
Each such configuration involves multiple register writes and reads
according to user provided inputs.
I don't really see how to generalize the information collection in a way
that would benefit anyone else.

> For your inhouse debugging, you should have oot
> patch to expose whatever you need.

I don't want in-house debugging capabilities -
I want field debug capabilities.