On Tue, Aug 18, 2015 at 1:47 PM, David Miller <da...@davemloft.net> wrote: > From: Scott Feldman <sfel...@gmail.com> > Date: Tue, 18 Aug 2015 13:37:56 -0700 >
>>>> > Hi Scott >>>> > >>>> > David is not so keen no debugfs stuff. He already NACKed adding more >>>> > than what is currently in DSA: >>>> > >>>> > https://lkml.org/lkml/2015/7/11/8 >>>> >>>> That patch added writable debugfs files, which I can see might be used >>>> as a back-door to program hardware. That does seem bad. >>> >>> I fully agreed with respect to write. But if you read the whole >>> message, David is also not happy with read only. >>> >>> I think before you spend too much more time on this, you need some >>> indication from David if he is going to merge it or not. >> >> David, please give us guidance on debugfs in drivers/net. Is there >> some criteria we can define to know when it's OK to use debugfs? > > The less you use it the better, seriously. > > I see some drivers where the foo_debugfs.c file is larger than the rest > of the driver. Once people start using it, it's like crack, and they > dump every single debugging widget they found useful at some point into > there. > > This is not what we want. Most things I see in debugfs support was > probably useful for debugging one particular bug but then it was never > really useful again in the future. Those kinds of things can be done > locally in someone's tree. > > I often see various kinds of "statistics" ending up in these things, > or register dumps, both of which are 'ethtool' or similar material. # git grep debugfs_create drivers/net ^^^ this is scary. I see some crazy things being done here. The writable nodes look like workaround driver/device bugs or to provide backdoor interfaces that don't exist natively. I say we clean up this mess. Just eliminating the writable files would force bugs to get fixed and get new interfaces defined. And replace readable files when interface exist (stats/reg). Finally, look for readable files that can be converted to new shared common interfaces. What's left should be read-only (S_IRUGO) files (no binary blobs) containing data unique for driver/device useful for field troubleshooting. I'm motivated. Next net-next cycle I'm going to go down the list with a big eraser. I'm sure I'll be a popular guy. -scott -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
