Date: Tue, 3 Dec 2013 12:13:41 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-net@freebsd.org Cc: "Justin T. Gibbs" <gibbs@scsiguy.com>, Roger Pau =?utf-8?q?Monn=C3=A9?= <royger@freebsd.org>, net@freebsd.org Subject: Re: Defaults for if_capenable and detecting user initiated changes Message-ID: <201312031213.41677.jhb@freebsd.org> In-Reply-To: <0E13D481-9D6D-4B52-A5AD-B671BF3A85AF@scsiguy.com> References: <0E13D481-9D6D-4B52-A5AD-B671BF3A85AF@scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201312031213.41677.jhb>