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 han
From: Casey Leedom
Date: Fri, 22 May 2015 16:49:03 +
> 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.
>
| From: David Miller [da...@davemloft.net]
| Sent: Thursday, May 21, 2015 12:30 PM
|
| The prevailing assumption is that it's OK to have configuration
| settings that can't be undone.
|
| And that's bogus from the beginning.
Oh I definitely understand that and agree. Unfortunately I've
inheri
From: Casey Leedom
Date: Thu, 21 May 2015 16:36:00 +
> I definitely understand the issue of wanting to avoid randomly
> different module parameters in various drivers which do similar
> things. What we're looking for is a list of the acceptable ways for
> doing things ― especially when they
| From: David Miller [da...@davemloft.net]
| Sent: Sunday, May 17, 2015 8:46 PM
|
| > From: Hariprasad Shenai
| > Date: Sun, 17 May 2015 16:15:21 +0530
| >
| > We now have a new cxgb4 module parameter "tx_vf" that when set
| > to a non-zero value, causes cxgb4 to use the "Virtual Machine" versio
From: Hariprasad Shenai
Date: Sun, 17 May 2015 16:15:21 +0530
> We now have a new cxgb4 module parameter "tx_vf" that when set
> to a non-zero value, causes cxgb4 to use the "Virtual Machine" version
> of the firmware Ethernet TX Packet Work Request (FW_ETH_TX_PKT_VM_WR)
> instead of the "normal"
