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
[e-mail]     \ /                  San Jose, California 95129-1034
[phone]         | g g d r a s i l   United States of America
fax [phone]      "Free Software For The Rest Of Us."