From owner-svn-src-stable-8@FreeBSD.ORG Sat Sep 10 11:35:54 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 36D621065672; Sat, 10 Sep 2011 11:35:54 +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 0F0518FC0A; Sat, 10 Sep 2011 11:35:54 +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 D622946B09; Sat, 10 Sep 2011 07:35:52 -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: <201109101310.24841.hselasky@c2i.net> Date: Sat, 10 Sep 2011 12:35:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: 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 11:35:54 -0000 On 10 Sep 2011, at 12:10, Hans Petter Selasky wrote: >> For most other classes of hardware device driver framework KPIs -- >> especially things like PCI bus attachment, busdma, CAM, ifnet, and = GEOM >> frameworks, our MFC rules would strictly disallow this sort of = change, on >> the grounds that it is our KBI policy that we not break common = classes of >> third-party device drivers (i.e., require them to be recompiled). My >> suspicion is that we should be applying the same rules to the USB >> framework -- however, I don't know if we have any third-party USB = device >> drivers? >>=20 >> (If we do, then this change should not have been MFC'd.) >=20 > 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. 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. Robert=