From owner-freebsd-net Fri Aug 16 7:27: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95CAA37B400; Fri, 16 Aug 2002 07:27:01 -0700 (PDT) Received: from baraca.united.net.ua (ns.united.net.ua [193.111.8.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8225243E6E; Fri, 16 Aug 2002 07:26:59 -0700 (PDT) (envelope-from max@vega.com) Received: from vega.vega.com (xDSL-2-2.united.net.ua [193.111.9.226] (may be forged)) by baraca.united.net.ua (8.11.6/8.11.6) with ESMTP id g7GEQhZ86553; Fri, 16 Aug 2002 17:26:44 +0300 (EEST) (envelope-from max@vega.com) Received: from vega.vega.com (max@localhost [127.0.0.1]) by vega.vega.com (8.12.5/8.11.3) with ESMTP id g7GEQbWe005814; Fri, 16 Aug 2002 17:26:37 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: (from max@localhost) by vega.vega.com (8.12.5/8.12.5/Submit) id g7GEQaxc005813; Fri, 16 Aug 2002 17:26:36 +0300 (EEST) From: Maxim Sobolev Message-Id: <200208161426.g7GEQaxc005813@vega.vega.com> Subject: Re: Increasing size of if_flags field in the ifnet structure [patch To: brandt@fokus.gmd.de (Harti Brandt) Date: Fri, 16 Aug 2002 17:26:36 +0300 (EEST) 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 In-Reply-To: <20020816160306.S24938-100000@beagle.fokus.gmd.de> from "Harti Brandt" at ΑΧΗ 16, 2002 X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > 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-net" in the body of the message