Defaults for if_capenable and detecting user initiated changes

[Justin T. Gibbs]

On Dec 3, 2013, at 10:13 AM, John Baldwin <jhb at freebsd.org> wrote:

> 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

Certainly this could be done in the Xen driver.  The reason I posted my question, however, was to ask whether this should be more generically tracked by the if layer instead of handled by the underlying driver.  Lots of user interfaces support a “restore defaults” capability (e.g. for the novice administrator who screws up, or as a step in writing a script/procedure that starts by getting to a known state), so I think this is interesting for more than this particular Xen issue.

—
Justin