[lkml]   [2001]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 4.1.0 DRM (was Re: Linux 2.4.6-ac3)
Keith Owens wrote:
> The clash occurred when two DRM objects were linked into the kernel, it
> resulted in two copies of the DRM code in vmlinux and ld spat the
> dummy. I did a workaround in drivers/char/drm/Makefile for the old
> code so that problem does not exist any more.

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.


> 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:57    [W:0.082 / U:1.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site