> > > If you want dynamic prints, you have two options: > > > 1. Add support of ethtool to whole RDMA stack. > > > 2. Use dynamic tracing infrastructure. > > > > > Which option do you prefer? > > Option 3 - continuing this discussion. :-) > > Sorry, > I was under impression that you want this driver to be merged, but it looks like It > was incorrect assumption. Let's continue discussion. No, this is an RFC - there's no chance for *this* to merge, but this is exactly the right time to discuss this sort of stuff. > > Perhaps I misread your intentions - I thought that by dynamic debug > > you meant that all debug in RDMA should be pr_debug() based, and > > therefore my objection regarding the ease with which users can > > configure it. > > It is not for all RDMA, but in your proposed driver. You are adding this "debug" > module argument to your module. I don't get your answer. I made a generic remark [and actually one in favor of your arguments], and instead of saying something meaningful you bash the driver. > > If all you meant was 'dynamically set' as opposed to 'statically set' > > then I agree that having that sort of configurability is preferable > > [Even though end-user would still probably prefer a module parameter > > for reproductions; As the name implies, 'debug' isn't meant to be used > > in other situations]. > > We are not adding code just for fun, but for a real reason, and especially > interfaces which will be visible to user. > > The overall expectation from the driver's authors that they are submitting driver > which doesn't have bringup issues. For real life scenarios, where the bugs will be > reveled after some time of usage, this global debug is useless. This has nothing to do with bringup; Real drivers are experiencing issues years after they're productized. > > Do notice you would be harming user-experience of reproductions though > > - as it would have to follow different mechanisms to open debug prints > > of various qed* components. > > I don't understand this point at all. Do you think that it is normal to ask user to > debug your driver? Is this called "user-experience"? No, I call this 'user involved in fixing the driver' - it has nothing to do with user-experience. Sometimes user have specifics in his system that can't be easily identified and thus lab reproductions fail, and the user assists in the reproduction. While I never claimed this is good practice it does happen. > As a summary, I didn't see in your responses any real life example where you will > need global debug level for your driver. Not sure what you you're expecting - a list of BZs /private e-mails where user reproductions were needed? You're basically ignoring my claims that such are used, instead wanting "evidence". I'm not going to try and produce any such. Doug - I think we need a definite answer from you here; Doesn't look like this discussion would bear any fruit. If a debug module parameter is completely unacceptable, we'd remove it [regardless of what I think about it]. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
