Skip to contentSkip to conversation

Happy new year^H^H^H^Hkernel..

DISCUSSION Rik Faith 2 participants 2 messages Jan 2, 2001

lore
Share & tools
lore

Rik Faith

author
#0 lore raw
Quoted 62 lines · Keith Owens
Quoted 42 lines · Linus Torvalds
Quoted 3 lines · Adam Sampson

It appears to work (even with the reiserfs patch with the obvious Makefile tweak), but the drm modules have unresolved symbols:

Does this fix it for you (do a "make clean" before re-building your tree)?

Linus

----

drivers/char/drm/Makefile renamed from linux/drivers/char/drm/Makefile +0 -0
@@ -44,22 +44,22 @@
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
drivers/char/drm/Makefile renamed from linux/drivers/char/drm/Makefile +0 -8
-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
-
-

# 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

drivers/char/drm/Makefile renamed from linux/drivers/char/drm/Makefile +1 -1
-  obj-y += drmlib.a
+  extra-obj = drmlib.a  

endif

drivers/char/drm/Makefile renamed from linux/drivers/char/drm/Makefile +8 -0
+
+obj-$(CONFIG_DRM_GAMMA) += gamma.o $(extra-obj)
+obj-$(CONFIG_DRM_TDFX)  += tdfx.o $(extra-obj)
+obj-$(CONFIG_DRM_R128)  += r128.o $(extra-obj)
+obj-$(CONFIG_DRM_FFB)   += ffb.o $(extra-obj)
+obj-$(CONFIG_DRM_MGA)   += mga.o $(extra-obj)
+obj-$(CONFIG_DRM_I810)  += i810.o $(extra-obj)
+
Quoted 1 line

include $(TOPDIR)/Rules.make

That will break for anybody compiling a DRM card into the kernel and compiling a second DRM card as a module. drmlib.a will get a split personality, it will be compiled twice, once for kernel and once for module, which version actually gets linked will depend on the phase of the moon. Either that or it only gets compiled for kernel, which is where we came in.

DRM maintainers: can we remove this restriction on needing multiple copies of the library? It makes no sense anyway. If you build a new library with the same function names then you cannot have two DRM cards built into the kernel, the function names will collide within vmlinux. So you have to use different function names for a new library, but then the old cards can share the old library and the new cards can share the new library, i.e. there is no need for each driver to have its own copy of the library.

Quoted 3 lines

I strongly recommend that you remove the restriction on having multiple copies of the library. Then Adam J. Richter's patch does the job nicely, making drmlib.a a helper module.

We plan to remove the need to have multiple copies of drmlib.a and make the kernel Makefile fully compatible with the 2.4 make system -- but we haven't finished this work yet. With this new work, however, the end-user will still load a single module (e.g., tdfx.o), just like now. (Loading a single kernel module is a significant win when dealing with end users: there is no possibility of version skew or of having two modules that were compiled with different options.)

Linus -- Please use your patch or Keith Owens' patch as a bandaid to solve this problem until we can do it the right way. Whatever patch you select, please do *NOT* make drmlib into a separate helper module -- this will only lead to user confusion (especially since we'll move back to a single-module solution soon). From the user's standpoint, I'm not concerned that you can't mix modules with in-kernel versions, since most users don't do that [and we could fix the configuration file to prevent this -- that's another way to bandage this problem that I'll send you a patch for tomorrow]. I am very concerned that users will see us move from 1 DRM module to 2 and then back to 1 -- that would be very confusing for them.

--Rik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#1 lore raw
Quoted 5 lines

haven't finished this work yet. With this new work, however, the end-user will still load a single module (e.g., tdfx.o), just like now. (Loading a single kernel module is a significant win when dealing with end users: there is no possibility of version skew or of having two modules that were compiled with different options.)

So with 3 video cards I have 3 wasted chunks of ram just because of a tiny tiny possibility that someone would manage to build two copies of the library with matching ksyms. That doesnt strike me as a good tade off
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/