Re: Happy new year^H^H^H^Hkernel..

[Rik Faith <faith@valinux.com>]

On Tue  2 Jan 2001 08:32:45 +1100,
   Keith Owens <kaos@ocs.com.au> wrote:
> On Mon, 1 Jan 2001 09:39:38 -0800 (PST), 
> Linus Torvalds <torvalds@transmeta.com> wrote:
> >On 1 Jan 2001, Adam Sampson wrote:
> >> 
> >> 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
> >
> >----
> >--- v2.4.0-prerelease/linux/drivers/char/drm/Makefile	Mon Jan  1 09:38:35 2001
> >+++ linux/drivers/char/drm/Makefile	Mon Jan  1 09:38:04 2001
> >@@ -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
> > 
> >-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
> >-  obj-y += drmlib.a
> >+  extra-obj = drmlib.a  
> > endif
> >+
> >+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)
> >+
> > 
> > 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.
> 
> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/