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]

Date:   Thu, 20 Apr 2017 16:24:51 +0000
From:   "Mintz, Yuval" <Yuval.Mintz@...ium.com>
To:     David Miller <davem@...emloft.net>
CC:     "jiri@...nulli.us" <jiri@...nulli.us>,
        "gerlitz.or@...il.com" <gerlitz.or@...il.com>,
        "jeffrey.t.kirsher@...el.com" <jeffrey.t.kirsher@...el.com>,
        "mitch.a.williams@...el.com" <mitch.a.williams@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "sassmann@...hat.com" <sassmann@...hat.com>,
        "jogreene@...hat.com" <jogreene@...hat.com>,
        "Dupuis, Chad" <Chad.Dupuis@...ium.com>,
        "Rangankar, Manish" <Manish.Rangankar@...ium.com>
Subject: RE: [net-next 04/14] i40e: dump VF information in debugfs

> > 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.
> 
> That's basically what everyone says who slaps random crap into debugfs. 

True; But assuming that means the suggestion to use debugfs means the
content is random crap is a logical fallacy.

> >> 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.
> 
> Then it has to use a portable, well defined, set of interfaces.

How would you be able to describe something that is completely tied
to a specific HW this way. E.g., let's assume you'd want to record
some messages that pass between 2 internal processors that match
some criteria?
While you can probably standardize some format from such a matching
[although that too would be very tied to different HW capabilities],
the HW pipeline itself can't be abstracted in this case.