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

Rik Faith (faith@valinux.com)
Tue, 2 Jan 2001 16:18:15 -0500 (EST)


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/