I would also like to discuss the possibility of: - dropping the DRM(my_func)() for drm_my_func(). If I'm not mistaken, these symbols aren't exported to the rest of the kernel so there isn't any conflict when several DRM's are loaded simulatenously on the kernel (or is there?) Besides of reducing some visual clutter this would allow to a better parity between the source code and the Doxygen generated documentation: at the moment those DRM(...) tags have to be eliminated before feeding into Doxygen to allow cross-referecing.
I think you would be fine with multiple modules, but I think it would break if you had multiple drivers built into the kernel. I'm not sure about that, though. If it doesn't break (or if we don't care), I'd be in favor of killing the DRM(...) stuff.
If a lot of this stuff really is that device independent, why don't we move it to a separate kernel module? That would save some memory when multiple DRM drivers are loaded at once.
A more pratical issue (assuming that everbody is OK with what I'm proposing here) is about the commiting procedure: - should I committing each module as I write, perhaps posting before review before commiting? (my favorite) - should I setup a seperate branch (plz no - I'm sick of branching and merging and branching again and... 8( ) - or should I just setup a big patch once everything is done and do it in one go?
I don't think this change is big enough to warrant a branch. I would do it one driver at a time, and post to dri-devel for review. After the first one or two everyone will probably be comfortable enough with it to just let you do the rest in peace. :) If you do one big patch it will be information over-load and you won't get many / any useful reviews.
------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
