Date: Fri, 16 Aug 2002 16:34:25 +0200 (CEST) From: Harti Brandt <brandt@fokus.gmd.de> To: Maxim Sobolev <max@vega.com> Cc: Harti Brandt <brandt@fokus.gmd.de>, Bruce Evans <bde@zeta.org.au>, Maxim Sobolev <sobomax@FreeBSD.ORG>, <hackers@FreeBSD.ORG>, <net@FreeBSD.ORG> Subject: Re: Increasing size of if_flags field in the ifnet structure [patch Message-ID: <20020816162923.S24938-100000@beagle.fokus.gmd.de> In-Reply-To: <200208161426.g7GEQaxc005813@vega.vega.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 16 Aug 2002, Maxim Sobolev wrote: MS>> MS>> On Fri, 16 Aug 2002, Maxim Sobolev wrote: MS>> MS>> MS>> MS>> MS>> On Fri, 16 Aug 2002, Maxim Sobolev wrote: MS>> MS>> MS>> MS>> MS>BTW, I've just realised that we can easily avoid breaking application MS>> MS>> MS>ABI by using currently unused ifr_ifru.ifru_flags[2] (aka. ifr_prevflags) MS>> MS>> MS>for storing another 16 flags. What do people think? MS>> MS>> MS>> MS>> The ifr_prevflags may be used by snmp daemons to provide the necessary MS>> MS>> atomic rollback. MS>> MS> MS>> MS>Could you please verify? Nothing in the base system uses it. Initially, MS>> MS>ifr_prevflags was added with the following log message (rev.1.50): MS>> MS> MS>> MS> Since ifru_flags is a short, we can fit in a copy of the flags MS>> MS> before they got changed. This can help eliminate much of the MS>> MS> gymnastics drivers do in their ioctl routines to figure this out. MS>> MS> MS>> MS>but no drivers are using it so far. MS>> MS>> I veryfied only net-snmp-current. It doesn't use it (I guess that MS>> variable is not SNMP-writeable in net-snmp). I use it however in the MS>> bsnmp daemon for NgATM. Its the only way to guarantee the atomicity MS>> required by SNMP. MS>> MS>> Removing something from the ABI which you cannot do otherwise from MS>> userspace is always a problem, because it may break 3rd party software MS>> (I mean not binary breakage, but functional breakage). MS>> MS>> Well, while thinking about it: With a user settable PROXY flag there is no MS>> way for an application to find out whether the flag was already set or not MS>> if the application sets it, excpect by inspecting the ifr_prevflags field. MS>> So two applications fiddling with this bit may entirly confuse each other. MS>> Count me as a vote for keeping the field and breaking binary compatibility MS>> instead of functionality. MS> MS>Hmm, I do not really see how this flag may help your application. To set or MS>reset some flag from if_flags you have to read current values of those MS>flags, so that you can use that value instead of ifr_prevflags. Of course MS>it introduces some tiny race condition, but I do not see how presence of MS>ifr_prevflags can help you in this case. Moreover, possibility of such MS>race IMO is quite low, as interface flags are usually updated very rarely. Well, yes, you are right that I cannot prevent the race. MS>Instead your bsnmp daemons should be using other ways to serialise write MS>access to interface flags (e.g. lock file). This would require all programs that fiddle with interface flags to use that same lock file (including ifconfig). It seems rather silly to me to use a heavy weight lock file, to fiddle with a kernel flag. Ok, I take my vote back :-) kill ifr_prevflags harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020816162923.S24938-100000>