Date: Fri, 16 Aug 2002 16:13:31 +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: <20020816160306.S24938-100000@beagle.fokus.gmd.de> In-Reply-To: <200208161354.g7GDsoup005697@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>BTW, I've just realised that we can easily avoid breaking application MS>> MS>ABI by using currently unused ifr_ifru.ifru_flags[2] (aka. ifr_prevflags) MS>> MS>for storing another 16 flags. What do people think? MS>> MS>> The ifr_prevflags may be used by snmp daemons to provide the necessary MS>> atomic rollback. MS> MS>Could you please verify? Nothing in the base system uses it. Initially, MS>ifr_prevflags was added with the following log message (rev.1.50): MS> MS> Since ifru_flags is a short, we can fit in a copy of the flags MS> before they got changed. This can help eliminate much of the MS> gymnastics drivers do in their ioctl routines to figure this out. MS> MS>but no drivers are using it so far. I veryfied only net-snmp-current. It doesn't use it (I guess that variable is not SNMP-writeable in net-snmp). I use it however in the bsnmp daemon for NgATM. Its the only way to guarantee the atomicity required by SNMP. Removing something from the ABI which you cannot do otherwise from userspace is always a problem, because it may break 3rd party software (I mean not binary breakage, but functional breakage). Well, while thinking about it: With a user settable PROXY flag there is no way for an application to find out whether the flag was already set or not if the application sets it, excpect by inspecting the ifr_prevflags field. So two applications fiddling with this bit may entirly confuse each other. Count me as a vote for keeping the field and breaking binary compatibility instead of functionality. 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-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020816160306.S24938-100000>