Defaults for if_capenable and detecting user initiated changes

[John Baldwin]

On Friday, December 06, 2013 11:25:48 am Justin T. Gibbs wrote:
> 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.

Hmm.  In terms of drivers where capenable can change at runtime, I think
Xen's netfront is unique in that regard.  However, it might be nice to know
what the defaults are (basically, what the initial setting of if_capenable
is).  You could even just cache that when if_attach() is called without
needing to  change any drivers, just add a new ifnet field that if_attach()
sets.

-- 
John Baldwin