From owner-freebsd-net@FreeBSD.ORG Mon Feb 20 23:42:54 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 4F9C31065672 for ; Mon, 20 Feb 2012 23:42:54 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id A81248FC0A for ; Mon, 20 Feb 2012 23:42:52 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.4/8.14.4) with ESMTP id q1KNG27f052133; Mon, 20 Feb 2012 17:16:02 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.4/8.14.4/Submit) id q1KNG2he052132; Mon, 20 Feb 2012 17:16:02 -0600 (CST) (envelope-from brooks) Date: Mon, 20 Feb 2012 17:16:02 -0600 From: Brooks Davis To: Marcel Moolenaar Message-ID: <20120220231601.GA51310@lor.one-eyed-alien.net> References: <338757D1-6B1E-49CF-983F-5D5851066FD3@xcllnt.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <338757D1-6B1E-49CF-983F-5D5851066FD3@xcllnt.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 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: Mon, 20 Feb 2012 23:42:54 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 16, 2012 at 08:16:22PM -0800, Marcel Moolenaar wrote: > All, >=20 > Juniper is in the final phases of creating a clean separation > between FreeBSD and Junos, so as to make upgrades of FreeBSD > easier. This also allows Juniper to track -current and be more > active FreeBSD contributors. >=20 > To that end, we have a short-term and hopefully short-lived > problem to solve, which is the ability to use FreeBSD's network > drivers against the Junos network stack. As some may know, the > Junos network stack has split up struct ifnet into a physical > and logical component, called ifdev and iflogical. >=20 > We've tried a few approaches to bridge the gap between ifnet > on the one hand and ifdev and iflogical on the other and found > that abstracting ifnet and using accessor functions is the > best way to allow us to use FreeBSD drivers with the Junos > network stack, while retaining the ability to use them with > the FreeBSD stack. >=20 > FreeBSD is also looking at breaking up ifnet and with that in > mind, I was wondering if there would be any resistance to > changing network drivers to use accessor functions or macros > instead of direct pointer dereferences? >=20 > For example, do something like: >=20 > Index: if_fxp.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- if_fxp.c (revision 231178) > +++ if_fxp.c (working copy) > @@ -823,13 +823,14 @@ > } > =20 > if_initname(ifp, device_get_name(dev), device_get_unit(dev)); > - ifp->if_init =3D fxp_init; > - ifp->if_softc =3D sc; > - ifp->if_flags =3D IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; > - ifp->if_ioctl =3D fxp_ioctl; > - ifp->if_start =3D fxp_start; > + if_set_init(ifp, fxp_init); > + if_set_softc(ifp, sc); > + if_set_flags(ifp, IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST, 0); > + if_set_ioctl(ifp, fxp_ioctl); > + if_set_start(ifp, fxp_start); > =20 > - ifp->if_capabilities =3D ifp->if_capenable =3D 0; > + if_set_capabilities(ifp, 0); > + if_set_capenable(ifp, 0); > =20 > /* Enable checksum offload/TSO for 82550 or better chips */ > if (sc->flags & FXP_FLAG_EXT_RFA) { >=20 > Such a scheme, while initially touching a lot of driver, > would make it easier to break up ifnet *and* also make it > easier to hide ABI/API changes from driver vendors (esp. > when the accessor functions are non-inlined functions and > not macros or inlines). This is particularly useful for > Juniper, where we have worked towards network stacks as > (pre-)loadable modules so as to help with migration and > validation. >=20 > Thoughts, feedback and suggestion are welcome, The concept seems fine to me and I like that it might simplify future API changes. Have you verified that if_get_*() accessors don't add significant overhead? I agree with the concern raised by Luigi about intra-branch compatability. My prefered solution to that would be to MFC the adition of the accessors pretty much instantly and to commit the changes to individual drivers seperately to allow them to be merged as needed by driver maintainers. -- Brooks --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFPQtQxXY6L6fI4GtQRAj8IAKDocTqq2HlozpiWThJ6VLrKIOtm4gCgh8K7 JgppnExMIp6BUvNb7fEohxQ= =2t9B -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG--