On Mon, Jun 02, 2003 at 09:07:16PM -0700, Ian Romanick wrote:
> Jos� Fonseca wrote:
> 
> >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.

I don't think the memory saving is very important, since multiple DRM
modules must be a rare thing anyway.

According with archives
(http://dri.sourceforge.net/doc/faq/architecture.html#DRM-SUB-DRIVERS),
Linus wanted the DRM drivers to be independent.  Don't know if he still
feels the same, considering the ALSA/OSS modules, or the recent
reorganization of AGPGART.  Don't know as well if the old "DRM
sub-drivers" would do the same thing as these examples.

Perhaps we can discuss again this after the janitorial is done, as I
don't want to give steps greater than my legs.

Jos� Fonseca


-------------------------------------------------------
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

Reply via email to