Okay, really: I’m not arguing for module parameters. I’m agreeing with you
100%.
I’m not trying to be snarky or back you into admitting that there are some times
when a module parameter is needed. I’m not being sneaky, etc. I’m really just
asking a mechanism question. It is, on the other hand, quite likely that I’m
being dumb. I’ll absolutely grant you that.
So let me turn this around and ask:
What command would you envision that I use in order to tell a driver
to use a different TX routine for an interface?
ethtool —tx-routine eth{n} loopback
Or?
Sorry for being so dense. We really are trying to live within the rules but
we’re struggling to figure out what patch we should submit.
Casey
> On May 22, 2015, at 11:01 AM, David Miller <da...@davemloft.net> wrote:
>
> From: Casey Leedom <lee...@chelsio.com>
> Date: Fri, 22 May 2015 16:49:03 +0000
>
>> Oh I definitely understand that and agree. Unfortunately I've
>> inherited a driver architecture that makes that ... "difficult"
>> for many operations ... And I have an internal bug filed
>> against me to fix those particular issues.
>>
>> However, that doesn't answer at least one of my questions
>> which was how do I pass information into the driver _before_
>> it does the device probe?
>
> I did answer the question, I said that if you fix the real actual
> core problem then you won't have this need to begin with.
>
> I thought I made that perfectly clear.
>
> I really am not going to entertain arguments of the form "it's
> too hard to implement this correctly so I'm going to try
> and slam a module parameter into the driver to fix things".
>
--
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
