From owner-freebsd-net@FreeBSD.ORG Tue Feb 21 17:13:31 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 CEE09106566B; Tue, 21 Feb 2012 17:13:31 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 79C148FC16; Tue, 21 Feb 2012 17:13:31 +0000 (UTC) Received: from sa-nc-apg-180.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q1LHDNCr028170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Feb 2012 09:13:29 -0800 (PST) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20120221090821.GE55074@deviant.kiev.zoral.com.ua> Date: Tue, 21 Feb 2012 09:13:18 -0800 Content-Transfer-Encoding: 7bit Message-Id: <1F812CB2-152F-47AF-9952-6AEAC6D95547@xcllnt.net> References: <338757D1-6B1E-49CF-983F-5D5851066FD3@xcllnt.net> <20120220231601.GA51310@lor.one-eyed-alien.net> <20120221001552.GA60050@onelab2.iet.unipi.it> <20120221090821.GE55074@deviant.kiev.zoral.com.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1257) Cc: Juli Mallett , 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 17:13:31 -0000 On Feb 21, 2012, at 1:08 AM, Konstantin Belousov wrote: > 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. >> >> 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. *snip* > You could take a look how mutexes or vm_page_locks are handled, > giving inlines for kernel proper and stable KBI for modules. A stable KBI is what we'll be aiming for at Juniper. We're working towards a kernel proper without any networking, the FreeBSD network stack as a module, the Juniper network stack as a module and H/W network drivers as modules. The network drivers and how they talk to the network stack is the big piece we still had to flesh out. Dynamic loading and unloading of network stack modules is not a goal, but we do want to be able to pre-load the network stack that we want to use and not have to worry about matching the H/W network drivers with the stack of choice. Inlines for the kernel proper and a stable KBI for modules seems to match everyone's objectives/concerns. We'll definitely take a look at the mutexes and vm_page_locks. FYI, -- Marcel Moolenaar marcel@xcllnt.net