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
| 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
From: Casey Leedom lee...@chelsio.com
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
From: Casey Leedom lee...@chelsio.com
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 ―
| From: David Miller [da...@davemloft.net]
| Sent: Sunday, May 17, 2015 8:46 PM
|
| From: Hariprasad Shenai haripra...@chelsio.com
| 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
From: Hariprasad Shenai haripra...@chelsio.com
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
