Defaults for if_capenable and detecting user initiated changes

[John Baldwin]

On Wednesday, November 27, 2013 12:59:08 pm Justin T. Gibbs wrote:
> Hi net,
> 
> I’m reviewing a patch from Roger Pau Monné for the Xen netfront driver.  The 
goal of the change is to avoid disturbing the user’s settings for the 
interface just because the backend device has changed or the connection to the 
backend was reset.  I’ve attached the latest version of the patch.
> 
> The current patch leaves the interface settings alone if they can be 
supported by the newly attached backend.  What would be ideal is to enable 
capabilities that default to being enabled if they were not explicitly 
disabled by the user and can be supported by the new backend.  Unfortunately, 
I don’t think the if_capenable and if_capabilities fields are descriptive 
enough to deal with an interface whose capabilities can change at runtime.  
Just as can be done with link speed, some of these settings need to allow an 
“auto/default” setting in addition to on or off.  This would allow the user to 
explicitly disable a capability if needed, but generally allow the system to 
chose the most optimal settings when they are supported.  Would this be 
difficult to add?

Couldn't you maintain this state in the Xen netfront driver's softc?
You already get the ioctls that track changes to the capenable field,
so you when a change explicitly disables a capability you can set that
in a 'forced off' or 'forced on' field.  Perhaps more of a 'forced'
field that you just update by doing:

	sc->capforced |= (oldcapenable ^ newcapenable)

However, it's not clear to me if you can get the underlying adapters
initial capenable list.  If so, I think capforced should be all you
need to handle this (though it might be easier if you have separate
forcedon and forcedoff fields).

-- 
John Baldwin