Re: Patch(?): linux-2.4.0-prerelease/drivers/char/drm/Makefile libdrm symbol versioning fix

Re: Patch(?): linux-2.4.0-prerelease/drivers/char/drm/Makefile libdrm symbol versioning fix

[Adam J. Richter]

>> = Adam Richter
>  = Keith Owens

>>	There is a thread in linux-kernel about how somewhere in
>>linux-2.4.0-test13-preX, the Makefile for drivers/char/drm started
>>building libdrm.a and not versioning the symbols.  I believe the
>>following patch fixes the problem, but I have not tried it for the
>>nonmodular case.
>>
>>	The change is that libdrm.o is built instead of libdrm.a.  This
>>object is linked into the kernel if at least one driver that needs it
>>is also linked into the kernel.  Otherwise, it is built as a helper
>>module which is automatically loaded by modprobe when a module that
>>needs it is loaded.

>Having drmlib.o as a helper module will defeat the requirements listed
>in drivers/char/drm/Makefile (below).  You end up with one copy of the
>library being used by all modules.  See my patch earlier today on l-k
>that builds two versions of drmlib.a, for kernel and module.  That
>patch preserves the drm requirements.

># libs-objs are included in every module so that radical changes to the
># architecture of the DRM support library can be made at a later time.
>#
># The downside is that each module is larger, and a system that uses
># more than one module (i.e., a dual-head system) will use more memory
># (but a system that uses exactly one module will use the same amount of
># memory).
>#
># The upside is that if the DRM support library ever becomes insufficient
># for new families of cards, a new library can be implemented for those new
># cards without impacting the drivers for the old cards.  This is significant,
># because testing architectural changes to old cards may be impossible, and
># may delay the implementation of a better architecture.  We've traded slight
># memory waste (in the dual-head case) for greatly improved long-term
># maintainability.

>BTW, I disagree with this approach but I guess it is up to the drm
>maintainers.

	Like you, I disagree with this approach, but, if I have not missed
some important information, then I hope the drm maintainers with see
the light or, failing that, the Linus will just delete those comments
from linux/drivers/char/drm/Makefile anyhow and integrate a patch like
the one I posted.

	Kernel interfaces change radically all the time, and we make better
tradeoffs to deal with the same issues of maintaining support for old
hardware which might not be tested right away all the time.  For example,
we currently maintain two styles of PCI device drivers.  The drm
maintainers could just write a libdrm2 library if the need arose and
depmod/modprobe would automatically load it when necessary if they designed
it the normal way.  Imagine how huge the kernel modules would be if every
facility in the kernel duplicated itself as an object file in every module.
Why should drm be treated differently?

	It an especially bad tradeoff to take on the maintenance costs
of a weird kernel build (that drm users are already complaining about on
linux-kernel) for a facility like drm, which is a graphics optimization
for applications that are willing to go to some trouble to use it.  Users
of these applications will be disproprionately quick to upgrade or (for
example, in embedded applications) some organization will care enough and
have resources enough to at least report bugs and test fixes.  This is
like recoding i386 floating point emulation into assembly.  The
performance/maintence tradeoff is not worth it, because 386's have
already obscelesced from those applications, and still would have, even
with FP emulation in assembly.

	It's not my call to make, and I think we will follow the stock
kernels' drivers/char/drm even if it continues this weirdness, but I
certainly hope this duplication of libdrm in every module will be dropped.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Patch(?): linux-2.4.0-prerelease/drivers/char/drm/Makefile libdrm symbol versioning fix

[Adam J. Richter]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

	There is a thread in linux-kernel about how somewhere in
linux-2.4.0-test13-preX, the Makefile for drivers/char/drm started
building libdrm.a and not versioning the symbols.  I believe the
following patch fixes the problem, but I have not tried it for the
nonmodular case.

	The change is that libdrm.o is built instead of libdrm.a.  This
object is linked into the kernel if at least one driver that needs it
is also linked into the kernel.  Otherwise, it is built as a helper
module which is automatically loaded by modprobe when a module that
needs it is loaded.  This change takes advantage of the new style
Makefile rules to achieve this end.  I think it basically is the
correct approach, although I have not yet tested compilation into
the kernel.

	Any testing and feedback would be appreciated.

-- 
Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

[-- Attachment #2: drm.diff --]
[-- Type: text/plain, Size: 1863 bytes --]

--- linux-2.4.0-prerelease/drivers/char/drm/Makefile	Fri Dec 29 14:07:21 2000
+++ linux/drivers/char/drm/Makefile	Fri Dec 22 01:50:11 2000
@@ -44,43 +44,37 @@
 mga-objs   := mga_drv.o   mga_dma.o     mga_context.o  mga_bufs.o  mga_state.o
 i810-objs  := i810_drv.o  i810_dma.o    i810_context.o i810_bufs.o
 
-obj-$(CONFIG_DRM_GAMMA) += gamma.o
-obj-$(CONFIG_DRM_TDFX)  += tdfx.o
-obj-$(CONFIG_DRM_R128)  += r128.o
-obj-$(CONFIG_DRM_FFB)   += ffb.o
-obj-$(CONFIG_DRM_MGA)   += mga.o
-obj-$(CONFIG_DRM_I810)  += i810.o
+obj-$(CONFIG_DRM_GAMMA) += gamma.o drmlib.o
+obj-$(CONFIG_DRM_TDFX)  += tdfx.o drmlib.o
+obj-$(CONFIG_DRM_R128)  += r128.o drmlib.o
+obj-$(CONFIG_DRM_FFB)   += ffb.o drmlib.o
+obj-$(CONFIG_DRM_MGA)   += mga.o drmlib.o
+obj-$(CONFIG_DRM_I810)  += i810.o drmlib.o
 
 
 # When linking into the kernel, link the library just once. 
 # If making modules, we include the library into each module
 
-ifdef MAKING_MODULES
-  lib = drmlib.a
-else
-  obj-y += drmlib.a
-endif
-
 include $(TOPDIR)/Rules.make
 
-drmlib.a: $(lib-objs)
+drmlib.o: $(lib-objs)
 	rm -f $@
-	$(AR) $(EXTRA_ARFLAGS) rcs $@ $(lib-objs)
+	$(LD) -r -o $@ $(lib-objs)
 
-gamma.o: $(gamma-objs) $(lib)
-	$(LD) -r -o $@ $(gamma-objs) $(lib)
+gamma.o: $(gamma-objs)
+	$(LD) -r -o $@ $(gamma-objs)
 
-tdfx.o: $(tdfx-objs) $(lib)
-	$(LD) -r -o $@ $(tdfx-objs) $(lib)
+tdfx.o: $(tdfx-objs)
+	$(LD) -r -o $@ $(tdfx-objs)
 
-mga.o: $(mga-objs) $(lib)
-	$(LD) -r -o $@ $(mga-objs) $(lib)
+mga.o: $(mga-objs)
+	$(LD) -r -o $@ $(mga-objs)
 
-i810.o: $(i810-objs) $(lib)
-	$(LD) -r -o $@ $(i810-objs) $(lib)
+i810.o: $(i810-objs)
+	$(LD) -r -o $@ $(i810-objs)
 
-r128.o: $(r128-objs) $(lib)
-	$(LD) -r -o $@ $(r128-objs) $(lib)
+r128.o: $(r128-objs)
+	$(LD) -r -o $@ $(r128-objs)
 
-ffb.o: $(ffb-objs) $(lib)
-	$(LD) -r -o $@ $(ffb-objs) $(lib)
+ffb.o: $(ffb-objs)
+	$(LD) -r -o $@ $(ffb-objs)

Re: Patch(?): linux-2.4.0-prerelease/drivers/char/drm/Makefile libdrm symbol versioning fix

[Keith Owens]

On Sun, 31 Dec 2000 21:52:16 -0800, 
"Adam J. Richter" <adam@yggdrasil.com> wrote:
>	There is a thread in linux-kernel about how somewhere in
>linux-2.4.0-test13-preX, the Makefile for drivers/char/drm started
>building libdrm.a and not versioning the symbols.  I believe the
>following patch fixes the problem, but I have not tried it for the
>nonmodular case.
>
>	The change is that libdrm.o is built instead of libdrm.a.  This
>object is linked into the kernel if at least one driver that needs it
>is also linked into the kernel.  Otherwise, it is built as a helper
>module which is automatically loaded by modprobe when a module that
>needs it is loaded.

Having drmlib.o as a helper module will defeat the requirements listed
in drivers/char/drm/Makefile (below).  You end up with one copy of the
library being used by all modules.  See my patch earlier today on l-k
that builds two versions of drmlib.a, for kernel and module.  That
patch preserves the drm requirements.

# libs-objs are included in every module so that radical changes to the
# architecture of the DRM support library can be made at a later time.
#
# The downside is that each module is larger, and a system that uses
# more than one module (i.e., a dual-head system) will use more memory
# (but a system that uses exactly one module will use the same amount of
# memory).
#
# The upside is that if the DRM support library ever becomes insufficient
# for new families of cards, a new library can be implemented for those new
# cards without impacting the drivers for the old cards.  This is significant,
# because testing architectural changes to old cards may be impossible, and
# may delay the implementation of a better architecture.  We've traded slight
# memory waste (in the dual-head case) for greatly improved long-term
# maintainability.

BTW, I disagree with this approach but I guess it is up to the drm
maintainers.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Patch(?): linux-2.4.0-prerelease/drivers/char/drm/Makefile libdrm symbol versioning fix

[Adam J. Richter]

On Mon, Jan 01, 2001 at 05:45:05PM +1100, Keith Owens wrote:
> Having drmlib.o as a helper module will defeat the requirements listed
> in drivers/char/drm/Makefile (below).  You end up with one copy of the
> library being used by all modules.  See my patch earlier today on l-k
> that builds two versions of drmlib.a, for kernel and module.  That
> patch preserves the drm requirements.
> 
> # libs-objs are included in every module so that radical changes to the
> # architecture of the DRM support library can be made at a later time.
> #
> # The downside is that each module is larger, and a system that uses
> # more than one module (i.e., a dual-head system) will use more memory
> # (but a system that uses exactly one module will use the same amount of
> # memory).
> #
> # The upside is that if the DRM support library ever becomes insufficient
> # for new families of cards, a new library can be implemented for those new
> # cards without impacting the drivers for the old cards.  This is significant,
> # because testing architectural changes to old cards may be impossible, and
> # may delay the implementation of a better architecture.  We've traded slight
> # memory waste (in the dual-head case) for greatly improved long-term
> # maintainability.
> 
> BTW, I disagree with this approach but I guess it is up to the drm
> maintainers.

	Like you, I also disagree with this approach, but I think it
is ugly enough and has so little justification that I see, that I
_currently_ hope that those comments from the Makefile will simply
be deleted.

	If radical changes were necessary, the drm maintainers could
always write libdrm2 and modules that needed that would pick it up via
depmod/modprobe.  We have radical changes all the time in kernel
interfaces (for example, the "new style" PCI initilialization) and deal
with the same issues of wanting to support old methods for old hardware
for a while.  Imagine if the rest of the kernel took this approach.

	The issue of supporting old hardware is particularly inapplicable
to drm, because drm, given that the shortcut to the framebuffer that is drm
is for situations where one is willing to go some trouble to get really
fast graphics performance.  Users of those applications will be
disproprortionately likely to keep up with hardware.  This is like
recoding i386 floating point into assembly language: the
performance vs. maintenance trade off is not worth it because 386's
have migrated to tasks where that performance is not valued at all
(otherwise they'd be upgraded to 486's at least).  And, yes, I am
saying that the approach of replicating the .o files is *harder*
to maintain, because it is an unusual build scheme and increases the
resource cost of enabling drm, encouraging small (such as boot-over-network)
systems to drop it.

	Also, from looking in the list of external symbols that the
drm modules resolve, it is also clear to me that replicating these
object files will not result in binary modules that work with many
kernel versions, if that is what they were aiming for.

	Anyhow, it is not my call, and there probably aren't any
more keystrokes for me to generate with respect to this issue, but
if there is not some information that I have missed about this issue,
then I sure hope that the drm maintainers will see the light or, if not,
that Linus overrules the drm maintainers if necessary and integrates a
patch like the one I posted and just deletes those comments from
drivers/char/drm/Makefile.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/