Date: 10 Sep 2003 17:59:08 +0100 From: Doug Rabson <dfr@nlsystems.com> To: John Baldwin <jhb@FreeBSD.org> Cc: arch@FreeBSD.org Subject: RE: When to burn those bridges Message-ID: <1063213147.26798.1.camel@builder02.qubesoft.com> In-Reply-To: <XFMail.20030910123049.jhb@FreeBSD.org> References: <XFMail.20030910123049.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1063213147.26798.1.camel>