Re: [Dri-devel] DRM patch for Linux 2.4.0-prerelease
On Thu 4 Jan 2001 14:27:22 -0700, Keith Whitwell <[EMAIL PROTECTED]> wrote: > It looks like this patch goes further than syncing with xfree 4.0.2, > but syncs with the dri trunk instead. There has been a version bump > in the mga drm module on the dri trunk to add a 'blit' ioctl. XFree > 4.0.2 will barf on this. You are correct. For anyone using XFree86 4.0.2 or tracking what we'd like to be included in Linux 2.4.0, please ignore all the drivers/char/drm/mga* diffs in the last patch that I sent. Ignoring those diffs will provide compatibility with XFree86 4.0.2 for the MGA driver. Sorry for the confusion. - 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/
Re: Happy new year^H^H^H^Hkernel..
On Tue 2 Jan 2001 08:32:45 +1100, Keith Owens <[EMAIL PROTECTED]> wrote: > On Mon, 1 Jan 2001 09:39:38 -0800 (PST), > Linus Torvalds <[EMAIL PROTECTED]> 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/MakefileMon 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.oi810_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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make agpsupport work with modversions
On Wed 18 Oct 2000 19:23:54 +0100, David Woodhouse <[EMAIL PROTECTED]> wrote: > Don't you need to deal with the !CONFIG_AGP case correctly? This should already be dealt with in the Makefile -- if !CONFIG_AGP, then the file that we've been talking about (agpsupport.c) isn't compiled. (So, yes, you can still customize a drm module for your specific kernel. But I'm arguing for the ability to build a generic drm module that will determine agpgart presence at run time and use it if needed.) > [EMAIL PROTECTED] said: > > [Note that the other way to fix this would be to export > > get_module_symbol all the time, and have it just search the available > > symbol space if CONFIG_MODULES is 'n'.] > > There is no available symbol space if CONFIG_MODULES is 'n'. Oh :( - 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/
Re: [PATCH] Make agpsupport work with modversions
On Wed 18 Oct 2000 10:49:24 -0700, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Wed, 18 Oct 2000, Christoph Hellwig wrote: > > > In article <[EMAIL PROTECTED]> you >wrote: > > > > > I have no idea what the get_module_symbol() code in question is trying to > > > do, but this should be _fixed_ and not just worked around. That's a bug. > > > > It gets the symbol of a function, that's name is passed as char * to > > get_module_symbol(). > > Oh, I know what get_module_symbol() does - I just don't understand why drm > would want to use it. There are basically no good uses for it, as far as > I'm concerned. > > I assume it's something about allowing modules to be loaded in the wrong > order. Some other drivers did hooks like this in times past. The right > solution was then, and is almost certainly now, to just remove the code in > question and force the correct load order. Just to clarify -- my use of get_module_symbol has nothing to do with load order. It has to do with allowing a drm module to work with or without the agpgart module loaded. If there's some other way to do this, I'll be happy to move to that. I'd like to preserve the ability to have one driver which works with each chipset family and not have to have separate drivers for PCI and AGP cards (or, rather, to have fewer instances of the drivers -- they already depend on SMP and MODVERSIONS, and that's a lot of overhead already if you just want to play Q3A :). I'd also like a dual-head system to be able to load the same drm module and just have it work for both the agp and the pci cards (this isn't supported yet, in case anyone is wondering). > Rik? Can this code just go away? See above and my mail from a few minutes ago. I'd like to keep it (with the naming changes John Levon proposed, even if we don't make it available when CONFIG_MODULES is 'n'). - 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/
Re: [PATCH] Make agpsupport work with modversions
On Wed 18 Oct 2000 09:43:43 -0700,
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 18 Oct 2000, John Levon wrote:
> >
> > I have only compile-tested the patch below with 2.4.0test10pre3 and
> > 2.2.18pre16 (some fuzz on apply). Hope it's right, I can't test if it
> > fixes the MODVERSIONS+in kernel agp+in kernel drm case. I tested kernel
> > and module cases.
>
> It looks better.
We apparently had never changed the Makefile over to the new format.
The dependency on CONFIG_MODULES is essentially orthogonal to this
problem.
> However, the fact that you need that dependency on CONFIG_MODULES _still_
> shows that something is wrong. That dependency should not be there, and
> the drm code should be fixed. Why does it care about CONFIG_MODULES at
> all? It should not, and it _must_ not do that.
>
> I have no idea what the get_module_symbol() code in question is trying to
> do, but this should be _fixed_ and not just worked around. That's a bug.
The get_module_symbol() call will get the agp symbols if agpgart is
available (either as a loaded module, or compiled into the kernel).
Some DRM drivers optionally make use of agpgart, so it's useful for
the DRM driver to look for agpgart support at run time even if it
isn't available (e.g., the R128 driver may use AGP on an AGP system,
but not on a PCI system; or you might have the same type of chip on an
AGP card and on a PCI card, and you'd like to be able to load the same
drm module for both cards).
There are several cases that the configuration can have:
CONFIG_AGP CONFIG_MODULES
n n or y no agpsupport.c, so no problem
m or y y agpsupport.c uses get_module_symbol,
and the drm runs with or without
agpgart support (which may or may
not be a module that may or may not
be loaded). [This is the reason
we're using get_module_symbol -- I
didn't realize it wasn't available
if CONFIG_MODULES was 'n'.]
y n This is the broken case, which can
be fixed if agpsupport.c uses the
#ifdef below -- this case ensures
that the agpgart module is built
into the monolithic kernel and we
can safely hardcode the function
names at compile time.
#ifdef CONFIG_MODULES
for (fill = &drm_agp_fill[0]; fill->name; fill++) {
char *n = (char *)fill->name;
*fill->f = (drm_agp_func_u)get_module_symbol(NULL, n);
DRM_DEBUG("%s resolves to 0x%08lx\n", n, (*fill->f).address);
if (!(*fill->f).address) agp_available = 0;
}
#else
drm_agp_fill[0].f = agp_free_memory;
drm_agp_fill[1].f = agp_allocate_memory;
drm_agp_fill[2].f = agp_bind_memory;
drm_agp_fill[3].f = agp_unbind_memory;
drm_agp_fill[4].f = agp_enable;
drm_agp_fill[5].f = agp_backend_acquire;
drm_agp_fill[6].f = agp_backend_release;
drm_agp_fill[7].f = agp_copy_info;
#endif
[Note that the other way to fix this would be to export
get_module_symbol all the time, and have it just search the available
symbol space if CONFIG_MODULES is 'n'.]
-
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/
Re: [Dri-devel] Re: [2.4.0test10-pre3]drm_proc_init incorrect when multiple device
On Sun 15 Oct 2000 23:37:21 +0100, Tigran Aivazian <[EMAIL PROTECTED]> wrote: > On Sun, 15 Oct 2000, Alan Cox wrote: > > > > or to write a "drmfs" (Al Viro's suggestion) or to abandon the original > > > design of not-sharing the code and do share it (my suggestion but of > > > course it's up to Rick and other maintainers of that code -- they know > > > better how to make their own life easier). > > > > Or you write a very thin 'drmcore' module. That just contains proc > > management, registration code and shared library functions that > > are useful. > > Alan, believe it or not, that is exactly what I suggested -- almost > literally, your words, except I called it drm_core.c :) In the interest of fixing this problem in a way that is portable to other operating systems, the best long-term solution seems to be to just remove the /proc support and provide similar support via the existing ioctl interface. Other OSs need this anyway, and there's really no good reason to have the support duplicated if it interacts poorly with /proc support in recent kernels. (And I don't think the amount of information is sufficient to justify a drmfs that folks will have to mount.) - 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/
