Date: Fri, 16 Aug 2002 17:26:36 +0300 (EEST) From: Maxim Sobolev <max@vega.com> To: brandt@fokus.gmd.de (Harti Brandt) Cc: max@vega.com (Maxim Sobolev), brandt@fokus.gmd.de (Harti Brandt), bde@zeta.org.au (Bruce Evans), sobomax@FreeBSD.ORG (Maxim Sobolev), hackers@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Increasing size of if_flags field in the ifnet structure [patch Message-ID: <200208161426.g7GEQaxc005813@vega.vega.com> In-Reply-To: <20020816160306.S24938-100000@beagle.fokus.gmd.de> from "Harti Brandt" at ΑΧΗ 16, 2002
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. Hmm, I do not really see how this flag may help your application. To set or reset some flag from if_flags you have to read current values of those flags, so that you can use that value instead of ifr_prevflags. Of course it introduces some tiny race condition, but I do not see how presence of ifr_prevflags can help you in this case. Moreover, possibility of such race IMO is quite low, as interface flags are usually updated very rarely. Instead your bsnmp daemons should be using other ways to serialise write access to interface flags (e.g. lock file). -Maxim 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?200208161426.g7GEQaxc005813>