From owner-freebsd-net Fri Aug 16 5:11:54 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 BE3CE37B400; Fri, 16 Aug 2002 05:11:47 -0700 (PDT) Received: from baraca.united.net.ua (ns.united.net.ua [193.111.8.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id C302B43E72; Fri, 16 Aug 2002 05:11:43 -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 g7GCBQZ80641; Fri, 16 Aug 2002 15:11:27 +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 g7GCBKWe005352; Fri, 16 Aug 2002 15:11:20 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: (from max@localhost) by vega.vega.com (8.12.5/8.12.5/Submit) id g7GCBDrL005351; Fri, 16 Aug 2002 15:11:13 +0300 (EEST) From: Maxim Sobolev Message-Id: <200208161211.g7GCBDrL005351@vega.vega.com> Subject: Re: Increasing size of if_flags field in the ifnet structure [patch To: bde@zeta.org.au (Bruce Evans) Date: Fri, 16 Aug 2002 15:11:13 +0300 (EEST) Cc: sobomax@FreeBSD.ORG (Maxim Sobolev), hackers@FreeBSD.ORG, net@FreeBSD.ORG In-Reply-To: <20020816204055.N6621-100000@gamplex.bde.org> from "Bruce Evans" 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 Thu, 15 Aug 2002, Maxim Sobolev wrote: > > > When implementing ability to switch interface into promisc mode using > > ifconfig(8) I've stumbled into the problem with already exhausted > > space in the `short if_flags' field in the ifnet structure. I need to > > allocate one new flag, while we already have 16 IFF_* flags, and even > > one additional flag which is implemented using currently free > > if_ipending field of the said structure. Attached patch is aimed at > > increasing size of if_flags to 32 bits, as well as to clean-up > > if_ipending abuse. Granted, it will break backward ABI compatibility, > > but IMO it is not a big problem. > > Why isn't it a bug problem? It affects an application ABI (most socket > ioctls). We have whole syscalls whose purpose is to avoid breaking > application ABIs back to about 4.3BSD. Some of them may even work. > > > Index: src/share/man/man4/netintro.4 > > =================================================================== > > RCS file: /home/ncvs/src/share/man/man4/netintro.4,v > > retrieving revision 1.20 > > diff -d -u -r1.20 netintro.4 > > --- src/share/man/man4/netintro.4 18 Mar 2002 12:39:32 -0000 1.20 > > +++ src/share/man/man4/netintro.4 15 Aug 2002 18:33:42 -0000 > > @@ -197,7 +197,7 @@ > > struct sockaddr ifru_addr; > > struct sockaddr ifru_dstaddr; > > struct sockaddr ifru_broadaddr; > > - short ifru_flags; > > + int ifru_flags; > > int ifru_metric; > > int ifru_mtu; > > int ifru_phys; > > This particular ABI seems to have been broken before (in if.h 1.50 on > 1999/02/09), since the actual struct has "short ifru_flags[2];" followed > by "short if_index;" instead of "short ifru_flags;", and it has 2 new > struct members at the end too. If the struct were actually as above, > then changing the short to an int would almost be binary compatible > since it would just expand ifru_flags to use the 2 bytes of unnamed > padding caused by the poor layout, so the struct wouldn't expand and > the other members wouldn't move. Enlarging ifru_flags itself might > only break big-endian machines (little-endian ones wouldn't notice > providing the padding is zeroed). > > > Index: src/share/man/man9/ifnet.9 > > Breaking kernel ABIs isn't so important. They should only be compatible > within major releases. BTW, I've just realised that we can easily avoid breaking application ABI by using currently unused ifr_ifru.ifru_flags[2] (aka. ifr_prevflags) for storing another 16 flags. What do people think? -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message