Dave Airlie wrote:
The only thing I can think off is maybe adding this stuff to another C file per driver but that probably isn't necessary ... the other idea I've had is to perhaps separate the function table when we get the full table done, then we can have tables per functionality group, i.e. adding the dma flush just for the gamma to that table makes it a bit ugly...
Okay I've just checked in this idea to the branch, and I've finished all the other drivers off and BSD (this is untested it built though..)
I'll look to what could be my next step now ..
I looked at the code currently in CVS. Is it the most recent? I know CVS commits to X.org servers are toast right now.
I do have a couple comments. Instead of having all the code like:
if ( dev->fn_tbl.foo )
def->fn_tbl.foo();I'd rather have drivers init all the functions to some generic, noop function. I think that makes the code a lot cleaner to read.
Also, I think it might be better to embed a pointer to the function table in the device's data structure rather than the table itself. If (when?) we go to a setup where we have a generic base structure that each of the drivers embeds and expands in it's structure, a pointer should be easier to work with. Actually, it might not matter much. That type of thing was a *big* deal for the libGL / *_dri.so re-work that I did, so I might just paranoid. You can't mix-and-match compiled kernel modules, so it may not matter.
Other than that, the changes look great!
------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
