From owner-freebsd-arch@FreeBSD.ORG Wed Sep 10 09:59:21 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 BC06016A4BF; Wed, 10 Sep 2003 09:59:21 -0700 (PDT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7ED3043FF5; Wed, 10 Sep 2003 09:59:20 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id h8AGxESO091634; Wed, 10 Sep 2003 17:59:18 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) h8AGx8Tj026519; Wed, 10 Sep 2003 17:59:08 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: John Baldwin In-Reply-To: References: Content-Type: text/plain Message-Id: <1063213147.26798.1.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 10 Sep 2003 17:59:08 +0100 Content-Transfer-Encoding: 7bit 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 16:59:22 -0000 On Wed, 2003-09-10 at 17:30, John Baldwin wrote: > On 10-Sep-2003 Doug Rabson wrote: > > On Wed, 2003-09-10 at 08:53, Eric Anholt wrote: > >> On Wed, 2003-09-10 at 00:15, John Baldwin wrote: > >> > On 09-Sep-2003 Doug Rabson wrote: > >> > > I haven't been paying much attention recently on release engineering > >> > > issues so probably I have missed something. When do people think is the > >> > > right time to branch off the 5.x line of development and set fire to the > >> > > bridges? > >> > > >> > Go ahead and kill the ISA compat drivers if you need to. I do think > >> > that you can probably do this work in a p4 branch until it is ready > >> > and delay the killing of compat shims until then maybe. > >> > > >> > > This led me back to the idea of multiple inheritance in kobj/newbus. > >> > > Using multiple inheritance for the smbus re-work makes the chip drivers > >> > > much simpler since they don't have to explicitly list the 'parent' > >> > > methods in their method tables. The same thing goes for cardbus too. On > >> > > these lines, I went back and read through Justin's old inheritance > >> > > patches. These patches supported single inheritance for multiple > >> > > interfaces at the cost of changing the driver API considerably. I've > >> > > been tinkering with an alternative approach which supports multiple > >> > > inheritance at the class level, almost preserving the driver API while > >> > > changing the ABI slightly. > >> > > >> > Yes, please. There is the same problem with agp(4) and the hostb(4) > >> > driver and agp(4) for Intel motherboards with onboard graphics and > >> > the drm(4) driver for the same graphics chip. > >> > >> I thought we wanted agp(4) to replace hostb(4) when agp would attach. > >> It's not the same problem for intel onboard graphics and the drm driver, > >> then, since we need both drivers for the DRM to work. I think keithw > >> solved this by making the agp driver provide a "drmsub" child device > >> which the i8x0 DRM attaches to. Would there be any problems with > >> putting that in CVS? > > > > That is exactly what Keith did for the i830. I have his patches for it > > and I was supposed to review and commit them but they kind of got pushed > > to the bottom of the pile due to my recent house move. Would you like to > > do the honours? As far as I'm concerned, the patches are commit-ready > > apart from some minor violations of style(9) which I don't really care > > about but others might. > > We still get texture corruption on the i830 that we are tracking down. > We also have several other problems with missed interrupts due to > lack of spl() usage in DRM. I also have the patches and can try > to clean them up and commit them once Keith signs off on them. > Back to the hostb problem: notice that agp can't be kldloaded because > it can't attach to hostb because hostb is attached to it. If agp > were a separate device instance from teh hostb device, then you could > kldload agp. My feeling about that was always that the hostb driver provides absolutely no added value in the system. When I was developing agp originally, I just nuked it and kldloading agp.ko worked just fine.