> 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. ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
