Fri, Aug 25, 2017 at 7:16 AM, Andrew Lunn <andrew@xxxxxxx> 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. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
