From owner-freebsd-hackers Fri Aug 16 5:28:38 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13F7F37B401; Fri, 16 Aug 2002 05:28:30 -0700 (PDT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5067443E65; Fri, 16 Aug 2002 05:28:29 -0700 (PDT) (envelope-from ikostov@otel.net) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 17fgDB-000AmP-00; Fri, 16 Aug 2002 15:28:17 +0300 Date: Fri, 16 Aug 2002 15:28:17 +0300 (EEST) From: Iasen Kostov To: Maxim Sobolev Cc: Bruce Evans , Maxim Sobolev , , Subject: Re: Increasing size of if_flags field in the ifnet structure [patch In-Reply-To: <200208161211.g7GCBDrL005351@vega.vega.com> Message-ID: <20020816152555.Y18061-100000@shadowhand.OTEL.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@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: > > > > 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? If something uses ifr_prevflags this could break compatibility, but if not it is the best solution I think :). > > -Maxim > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message