RE: [RFC 02/11] Add RoCE driver framework

quoted

quoted

If you want dynamic prints, you have two options:
1. Add support of ethtool to whole RDMA stack.
2. Use dynamic tracing infrastructure.

quoted

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.

quoted

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.

quoted

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.

quoted

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html