Dave Airlie wrote:
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.
I've thought about this and wasn't sure how acceptable adding a load of NOP function calls would be.. I'm not sure too many of the current ptrs are in any fast paths, my preference was to use a macro which wrap the above but that may be the old way of thinking :-),
Since very few (any?) of the functions have a return value, couldn't you just use the same function for all of them?
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.
At the moment each driver has its own dev_private portion that is adds to so the central structure shouldn't change that often once the cleanups are done ...
You can't mix-and-match compiled kernel modules, so it may not matter.
I really don't want to have to introduce versioning between the drm kernel module and the card dependant one.. I can see people building their own card drivers from the DRM CVS and trying to load them vs a kernel with a built-in DRM core.. my current thinking on this is we use the Kconfig to try and ban it (I hope it is flexible enough)... so if a kernel has a built-in drm library CVS won't build against it, and we won't build DRM modules unless the library is a module ..
I'm now starting to recall some of the other arguments against a generice DRM library layer. Versioning like this in user-mode is yucky enough, but in the kernel it's yucky * 10. We really want to have device-independent code API version "X" only try to run with device-dependent code API version "X". Even with the device-independent layer as a module this is non-trivial. The user might have another device-dependent module that matches the existing device-independent code. Ugh.
I guess one (unpleasant) way to make it work would be to add the version to all the symbols in the device-independent layer. Instead of drm_foo you'd have drm_foo_100 or drm_foo_101 or whatever. You could then have multiple modules loaded or a module loaded with a built-in version. I'm not sure how happy that would make the kernel maintainers (not to mention how happy it would make us). :( It's basically like what we have now, except the current code has the device's name add to all the symbols and is built into the device-dependent module. Ugh, ugh.
How do other multi-layer kernel modules handle this? For example, how does agpgart or iptables do it?
------------------------------------------------------- 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
