[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BL2PR07MB23063D7F1341E629E9345F578D1B0@BL2PR07MB2306.namprd07.prod.outlook.com>
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.
Powered by blists - more mailing lists