I'd like to request comments on the appended; proposed patch for 2.4 to
export the symbol "mmu_cr4_features".
This is needed by the XFree86 DRM kernel drivers, since Christoph's
backport of vmap() in 2.4.22-pre7. [some] DRM kernel drivers (e.g. radeon]
refuse to load without this fix, from 2.4.22-pre7 onwards.
cheers,
Calum.
[diffs -u against 2.4.22-pre9]
--- arch/i386/kernel/setup.c.20030731 2003-07-31 11:28:52.000000000 +0100
+++ arch/i386/kernel/setup.c 2003-08-01 12:42:21.000000000 +0100
@@ -128,6 +128,7 @@
struct cpuinfo_x86 boot_cpu_data = { 0, 0, 0, 0, -1, 1, 0, 0, -1 };
unsigned long mmu_cr4_features;
+EXPORT_SYMBOL(mmu_cr4_features);
/*
* Bus types ..
--- arch/x86_64/kernel/setup.c.20030731 2003-07-31 11:28:53.000000000 +0100
+++ arch/x86_64/kernel/setup.c 2003-08-01 12:43:27.000000000 +0100
@@ -30,6 +30,7 @@
#include <linux/blk.h>
#include <linux/highmem.h>
#include <linux/bootmem.h>
+#include <linux/module.h>
#include <asm/processor.h>
#include <linux/console.h>
#include <linux/seq_file.h>
@@ -58,6 +59,7 @@
};
unsigned long mmu_cr4_features;
+EXPORT_SYMBOL(mmu_cr4_features);
/* For PCI or other memory-mapped resources */
unsigned long pci_mem_start = 0x10000000;
On Fri, Aug 01, 2003 at 01:52:50PM +0100, Calum Mackay wrote:
> I'd like to request comments on the appended; proposed patch for 2.4 to
> export the symbol "mmu_cr4_features".
>
> This is needed by the XFree86 DRM kernel drivers, since Christoph's
> backport of vmap() in 2.4.22-pre7. [some] DRM kernel drivers (e.g. radeon]
> refuse to load without this fix, from 2.4.22-pre7 onwards.
Can you explain why they need it and why they magically need it
because of vmap() ?
Christoph Hellwig wrote:
> Can you explain why they need it and why they magically need it
> because of vmap() ?
Sorry, of course.
[as Mitch has already pointed out privately] e.g the XFree86 DRM radeon
Makefile includes this:
[xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Makefile.linux]
# Check for 4-argument vmap() in some 2.5.x and 2.4.x kernels
VMAP := $(shell grep -A1 'vmap.*count,$$'
$(LINUXDIR)/include/linux/vmalloc.h | grep -c prot)
ifneq ($(VMAP),0)
EXTRA_CFLAGS += -DVMAP_4_ARGS
endif
Christoph's vmap() backport introduced this reference in
linux/vmalloc.h, so the DRM module is now compiled with VMAP_4_ARGS defined.
The radeon kernel driver source includes (via drm_memory.h)
linux/vmalloc.h, iff VMAP_4_ARGS is defined. The latter includes (on
i386) asm/asm-i386/pgtable.h, which includes asm/asm-i386/processor.h.
processor.h defines some inline functions [set_in_cr4() &
clear_in_cr4()] which reference mmu_cr4_features.
mmu_cr4_features is currently declared in arch/i386/kernel/setup.c [and
also arch/x86_64/kernel/setup.c] but not currently exported.
[The problem is not restricted to the radeon kernel driver; I've just
used it as an example]
cheers,
Calum.
Calum Mackay wrote:
> The radeon kernel driver source includes (via drm_memory.h)
> linux/vmalloc.h, iff VMAP_4_ARGS is defined. The latter includes (on
> i386) asm/asm-i386/pgtable.h, which includes asm/asm-i386/processor.h.
>
> processor.h defines some inline functions [set_in_cr4() &
> clear_in_cr4()] which reference mmu_cr4_features.
Sadly, this isn't the full story, since the radeon code doesn't
reference *_in_cr4.
The radeon code calls io/agp remap functions - again only ifdef
VMAP_4_ARGS - which do however call __flush_tlb_all(). This manipulates
the PGE bit via mmu_cr4_features.
apols for the spam...
cheers,
Calum.