On Mon, 2 Jun 2003, Ian Romanick wrote:
>
> 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.
Yes.
The reason for DRM(xxx) is that I personally _require_ that built-in
modules work. If something works only as a loadable module, it's
broken-by-design, and I will complain very very loudly.
There have been other ways to solve the same thing (ie a common library
works fine, and is what many other drivers use), but DRM has historically
had slightly different functions for different drivers, and the DRM
makefiles have always been pretty broken.
> 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.
Kernel modules that depend on each other are a major pain in the butt, I
can tell you. It's not worth it from a technical angle, and one argument
against it has historically been that X binaries did something an "insmod
xxx" and the people didn't want to break that by requireing multiple
modules.
The only really sane approach is to just compile in the shared code.
Loadable modules are _way_ overrated, there's no inherent goodness in them
(and there are real downsides). The DRI project has been stuck with them
only because development is done outside the kernel.
I'd suggest making the truly common and hw-independent routines (and
_stable_ stuff) just be compiled into the kernel. Make the module thing an
option for development, but if it's really stable, it really is better off
being in the standard kernel - the same way you already depend on AGP
support being with the standard kernel. The library routines would be
available as a module only for backwards compatibility reasons.
Linus
-------------------------------------------------------
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
