On Fri, Dec 29, 2006 at 04:13:24PM +0100, Vincent wrote:
> it gets with bus_space_map, or that it calculates with bus_space_vmap 
> the corresponding virtual address range and publishes it through a 
> special function.

This sounds all backward. What DRI part are we talking about? 
Is this the chip specific driver that provides abstract DRI services and
attaches to the same hardware as, for example, vga @ pci?

There are a lot of different ways to organize this. Maybe we even need to
allow multiple of them:

  - vga @ pci and radeondri @ agp both share the hardware via some (tm)
    kind of cooperation.
  - radeondri @ agp owns the hardware, and allows vga @ radeondri (by
    forwarding some of it's bus_space variables, restricted to the common
    vga set)
  - radeondri @ agp completely replaces vga @ pci and directly allows
    wsdisplay @ radeondri (probably using code shared with vga @ pci)

The last case is especially interesting for other archs, e.g. ffb @ mainbus
on sparc64, where there are provisions for DRI support, but no PCI involved
at all. This, however, does not imply that we need to only select this way.

I personally would go the second way on PC, and the third on "strange" archs.
I prefer the second alternative over the first because the chip specific DRI
driver sure knows better what to bus_space_map, while vga @ pci does not and
the attaching dri part would have to deal with additional mappings later,
and maybe even need to temporarily undo the original ones.

Martin