Hi Greg, On Tue, May 29, 2018 at 06:51:54PM +0200, Greg Kroah-Hartman wrote: > On Tue, May 29, 2018 at 11:34:34AM -0500, Pete Zaitcev wrote: > > On Tue, 29 May 2018 17:30:50 +0200 > > Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > When calling debugfs functions, there is no need to ever check the > > > return value. The function can work or not, but the code logic should > > > never do something different based on this. > > > > Okay, fair enough. And the code works, surprisingly, even when the > > debugfs is disabled (well, according to my review). I just have one > > question - wouldn't it be cleaner to deprecate and remove the text > > API altogether? > > If you think we can do that, sure! But what's the odds that someone > still uses it? This patch doesn't change any real functionality. I had some use of this text API last year, when I also discovered and submitted and fix for its data corruption problems described in commit a5f596830e27e "usb: usbmon: Read text within supplied buffer size". A significant disadvantage with the text API is, as far as I understand it, that it can drop events (due to its buffering limit) without informing API readers (via event sequence numbers or some such). I've found a couple of USB bugs/problems (commit d6c931ea32dc0 "USB: OHCI: Fix NULL dereference in HCDs using HCD_LOCAL_MEM" for instance) and I'm still investigating at least one bug possibly related to lost interrupts where some kind of probing method could be helpful. However, I would explore other kernel probing methods for that. Not only because I'm curious but also because I have the impression that there are more powerful methods available than this text API. Would you recommend any alternatives? Fredrik -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
