Re: Multiple drivers for same hardware:, was: DRM and pci_driverconversion

[James Simmons]

> Since they have to co-operate some way on the resources _anyway_, they'll 
> just need to work it out amongst themselves.
> 
> One common case is to have a "arbitration driver" that tends to do the
> actual low-level accesses and is one level of abstraction over the
> hardware (papers over trivial differences in hardware). An example of this
> would be the old-style ISA DMA infrastructure (now happily pretty much
> dead), where the "DMA driver" was just a trivial layer that had some basic
> allocation/deallocation and had somewhat nicer access routines than the
> raw IO accesses, but didn't do much more.

I already have thought ahead about this issue. That is why one of the 
major changes to the framebuffer layer was to seperate the driver data 
into struct fb_info and a struct xxx_par. The idea was the data in struct 
fb_info was for the framebuffer layer and the data in struct xxx_par could 
be shared with other interfaces like DRI. The par idea can be extended 
further and we could use a common structure between a low level text mode
console driver and a graphics driver. For example mdacon and hgafb. 



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/