From owner-freebsd-arch@FreeBSD.ORG Wed Sep 10 01:08:14 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72BFB16A4BF for ; Wed, 10 Sep 2003 01:08:14 -0700 (PDT) Received: from herring.nlsystems.com (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id F040C43FB1 for ; Wed, 10 Sep 2003 01:08:12 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [10.0.0.2] (herring.nlsystems.com [10.0.0.2]) by herring.nlsystems.com (8.12.9/8.12.8) with ESMTP id h8A87igs047168; Wed, 10 Sep 2003 09:07:44 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: "M. Warner Losh" In-Reply-To: <20030909.190335.130622954.imp@bsdimp.com> References: <1063106587.25817.23.camel@builder02.qubesoft.com> <20030909.190335.130622954.imp@bsdimp.com> Content-Type: text/plain Message-Id: <1063181264.43759.6.camel@herring.nlsystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 10 Sep 2003 09:07:44 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@freebsd.org Subject: Re: When to burn those bridges X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2003 08:08:14 -0000 On Wed, 2003-09-10 at 02:03, M. Warner Losh wrote: > If there's a really compelling reason (and this would be it), we can > burn some bridges early. I wouldn't hold up your development based on > these bridges being in harm's way. Others in the BSDcon terminal room > are saying "do it now, screw waiting for 6". If you can get it done > and solid, I'd do it before the branch. The drivers in harm's way > either have out of tree replacements, or aren't that important, or > need to be redone and this is a good excuse. If I commit this work to -current now, it will break ABI compatibility with 5.1-RELEASE. When is the ABI for 5.x suppose to be frozen? Does it matter if I break the 5.1 ABI in current? For what its worth, this change will also make the kobj method dispatch SMP safe (without locks). > > : It would also be nice to have some kind of inheritance tree for device > : classes. Currently, drivers are grouped by devclass and the driver > : matching election is done by iterating through the drivers listed in the > : parent device's devclass. This means that many drivers have several > : attachment declarations for different alternatives, e.g.: > : > : DRIVER_MODULE(fxp, pci, fxp_driver, fxp_devclass, 0, 0); > : DRIVER_MODULE(fxp, cardbus, fxp_driver, fxp_devclass, 0, 0); > > Many cardbus drivers do nothing different. There are a few that do, > but so long as it is possible to override things if they want it. Drivers which really need something special for cardbus will be able to override things by defining a subclass of their pci driver which is listed in the cardbus devclass. > > : The same technique could be used to reduce the number of 'converter' > : devices. > > I like this. pcic/cbb have similar issues, but the size of the > problem is small. Its mainly a cosmetic thing but it has always been an irritation to me to have these little clusters of devices where there is only one piece of hardware, e.g.: hostb0 pci0 pcib1 pci1 amdpm0 smbus0 smb0 should become: pci0 pci1 amdpm0