Yes, I remember now.
> But even with that workaround, if one DRM object is a module and
> another is built in, the code in drmlib.a sometimes gets compiled for a
> module and sometimes for built in. AFAIK this does not cause any
> problems but is ugly. Come to that, the entire drm/Makefile is ugly.
Agreed.
> Note that these problems are not caused by code vs. macros, they are a
> direct effect of the insistence that each DRM object has its own set of
> routines instead of sharing common code. Using macros removes drmlib
> but still propagates the idea of not sharing code. As long as it does
> not get in the way of kbuild then I am happy, others may disagree about
> the approach.
The problem is that the "common code" isn't entirely common. In most
instances, the previously-duplicated code would be different in some
way, with the ordering of initialisation being fairly strict. The
templates allow for this to occur, with the "common code" residing
outside each driver, at least at the source code level.
There may be a way to get true runtime sharing happening, but again,
you'd have to talk to the guys at VA about this.
-- Gareth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/