> >> > 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.
