Date: Wed, 10 Sep 2003 18:39:27 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Doug Rabson <dfr@nlsystems.com> Cc: arch@FreeBSD.org Subject: RE: When to burn those bridges Message-ID: <XFMail.20030910183927.jhb@FreeBSD.org> In-Reply-To: <1063213147.26798.1.camel@builder02.qubesoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10-Sep-2003 Doug Rabson wrote: > 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. I don't mind if hostb were to die, but it does serve somewhat of a purpose. A dummy vga driver might also be useful with Warner's PCI power management stuff as well. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20030910183927.jhb>