From owner-freebsd-net@FreeBSD.ORG Tue Feb 21 13:14:28 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A94DB1065679 for ; Tue, 21 Feb 2012 13:14:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 1F0818FC18 for ; Tue, 21 Feb 2012 13:14:27 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1L98PSO054021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Feb 2012 11:08:26 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q1L98MUp057265; Tue, 21 Feb 2012 11:08:22 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1L98LSn057264; Tue, 21 Feb 2012 11:08:21 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 21 Feb 2012 11:08:21 +0200 From: Konstantin Belousov To: Juli Mallett Message-ID: <20120221090821.GE55074@deviant.kiev.zoral.com.ua> References: <338757D1-6B1E-49CF-983F-5D5851066FD3@xcllnt.net> <20120220231601.GA51310@lor.one-eyed-alien.net> <20120221001552.GA60050@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Epv4kl9IRBfg3rk" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Marcel Moolenaar , Adrian Chadd , Brooks Davis , Luigi Rizzo , net@freebsd.org Subject: Re: Abstracting struct ifnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 13:14:28 -0000 --4Epv4kl9IRBfg3rk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 20, 2012 at 06:42:15PM -0800, Juli Mallett wrote: > On Mon, Feb 20, 2012 at 18:34, Adrian Chadd wrote: > > Is the target though _binary_ compatibility? Just having a blessed > > method of doing accessor method things will buy more source > > flexibility. The KBI can stay the same in the default case and IMHO > > this kind of thing gives developers more power to do smart invariant > > and debugging things. >=20 > KBI compatibility requires very little discipline and makes loadable > modules for network drivers much less hellish. Inlines, macros and > full visibility of ifnet in -current may be useful, but unless there's > a performance reason for doing so, retaining KBI compatibility *and* > the ability to merge ifnet changes to -stable sounds pretty nice to > me. >=20 > > Being able to say "inform me every time an interface flag changes" > > would actually be kind of nice when debugging some of the issues i've > > been facing with ath. I've been half tempted to do this -inside- the > > ath driver, partially to restore the OS portability it once tried to > > achieve. >=20 > I think that it is rare that this is useful in debugging, and > something of a red herring. Even invariants are almost a red herring: > really, we shouldn't be using these individual methods to tweak > structure fields, either, we should have a way of describing a network > driver more semantically, such that the invariants are richer and also > not as complicated, and also more comprehensive. >=20 > Source compatibility is the biggest win, but a little self-discipline > to win what measure of binary compatibility we can seems perfectly > sensible. >=20 > (And at some point, we could even replace ifnet with something that's > less of a strange grab bag assortment that's awkward to explain to new > driver writers, and keep both source and binary compatibility for a > reasonable period in doing so. Unlikely to happen in the near term, > but wouldn't it be nice? You could take a look how mutexes or vm_page_locks are handled, giving inlines for kernel proper and stable KBI for modules. --4Epv4kl9IRBfg3rk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9DXwUACgkQC3+MBN1Mb4hsFwCgr0yi86G8vk6twSzE8mOuIVNU f4AAoIYmqYiON5SYsi8i4//VuYsrEN37 =xETU -----END PGP SIGNATURE----- --4Epv4kl9IRBfg3rk--