From owner-svn-src-stable-8@FreeBSD.ORG Sat Sep 10 12:24:34 2011 Return-Path: Delivered-To: svn-src-stable-8@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A2C31065670; Sat, 10 Sep 2011 12:24:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5B0EE8FC14; Sat, 10 Sep 2011 12:24:34 +0000 (UTC) Received: from [192.168.2.112] (host86-162-157-222.range86-162.btcentralplus.com [86.162.157.222]) by cyrus.watson.org (Postfix) with ESMTPSA id CC34A46B06; Sat, 10 Sep 2011 08:24:32 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: Date: Sat, 10 Sep 2011 13:24:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3406F3E2-56E6-47FF-8A60-10DD9F3B3D10@FreeBSD.org> References: <201109090744.p897iE9x027234@svn.freebsd.org> <201109101310.24841.hselasky@c2i.net> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1084) Cc: svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-8@freebsd.org Subject: Re: svn commit: r225458 - in stable/8/sys: dev/usb dev/usb/quirk dev/usb/storage sys X-BeenThere: svn-src-stable-8@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for only the 8-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2011 12:24:34 -0000 On 10 Sep 2011, at 12:35, Robert N. M. Watson wrote: >> I understand your point. The change is not breaking any KPIs towards=20= >> userspace. The structure in question is only used within the kernel = and kernel=20 >> modules. >=20 > Right -- exactly my point. If this change breaks third-party compiled = USB device drivers, then our current approach to device driver KBIs does = not allow it to be MFC'd in this form. Are there ways you can = reformulate the change to avoid breaking those drivers? Sometimes this = can be done by adding new symbols, rather than replacing currently = symbols, although mileage varies. FYI, you can find our rules for modifications to many network stack data = structures here: http://wiki.freebsd.org/NetKPIKBI We're willing to make rather extensive changes to in-kernel data = structures between major releases, but between minor releases we modify = kernel structures frequently used by device drivers only according to = specific rules. Some are essentially immutable -- for example, struct mbuf, as = assumptions about their size, layout, and interpretation are embedded in = hundreds of kernel modules. Others, such as struct ipq, are only = allocated by base kernel components, so you can safely extend them = without breaking device drivers that incorporate earlier assumptions = about layout (they just don't see new fields, which is often fine). Some = contain explicit padding put in before the .0 release to allow new = features to be added subject to constrained rules -- for example, we = often put additional padding fields into struct inpcb so that we can add = new well-defined features after the release, but can't grow the = structure due to it being embedded. Over time, we've been trying to make the ABI/KBI more robust by... (1) Attempting to divorce kernel data structures from user data = structures as much as possible, allowing kernel data structures to be = changed without requiring application modification. (2) Attempting to document which data structures can change and in what = ways (vis the above wiki page) so that there's a mutual understanding = about what can be done. (3) Think about what features will be added early in major release = cycles -- hence announcements of a "padding day" earlier in the 9.0 = cycle, and explicit commits to add necessary padding. (4) Avoid embedding base kernel data structures within module data = structures or allowing use of stack allocation of those structures. For = example, historically, BSD device drivers would embed "struct ifnet" = inside their per-drive softc. Now, the base kernel is responsible for = allocating struct ifnet's, and per-driver softc's have a pointer to the = ifnet allocated by the kernel. This adds more indirection in some cases, = but can significantly improve robustness. (5) In more extreme cases, disallow direct field access on data = structures entirely, requiring modules to treat them as opaque and = access fields via accessor functions. We don't use this approach all = that much, but have (for example) used it in inpcb locking, as it = allowed us to migrate from mutexes to rwlocks transparently, as well as = change other aspects of locking strategy. We use this in the MAC = Framework and a number of other places to achieve higher levels of = abstraction that will allow us to change (for example) label allocation = strategies between minor versions. Apple takes this much further than = us: in XNU, all access to mbuf fields is done via accessor functions, = allowing them to change the layout of mbufs without breaking device = drivers (such that device drivers can work with multiple major Mac OS X = versions). This presumably comes at a measurable cost that they deem = appropriate given the specifics of their end-user requirements. Another advantage to documenting KPIs/KBIs in a formal way is that it = actually gives us more flexibility to break other interfaces -- they = aren't on the list we advertise as being stable. We would benefit from = doing a much better job at this, but have been trying to be more = structured in the network stack, especially, due to a high demand for = fundamental code changes in support of new features. Robert=