Instead of patching kernel/module.c and maintaining a separate list of
module related profiling data, use the kernel_data field in struct
module. I added that field specificially so to track any kernel data
that relates to each module.
Change the module_arch_init() and free_module() functions in
include/asm-i386/module.h to allocate and free the kernel_data
structure during module load and unload. Take the profile lock in
those routines (disabling interrupts) when you update kernel_data.
To map a profile eip to a module, run the module list looking for the
address, see kernel_text_address() in arch/i386/kernel/traps.c for
example code.
With this approach, the mainline module code is unchanged, all arch
specific profile code is in include/asm-$(ARCH)/module.h.
Your srch_prof_buffer() algorithm is ix86 specific, you assume that
modules are always above the end of the kernel. That is not true on
all architectures. The correct method is to treat the kernel as just
another module and store the profile data for the kernel in
kernel_module.kernel_data, using arch_init_modules(). Running the
module list (which includes the kernel itself) will find the correct
address range in an architecture portable way. Add one extra slot to
the kernel profile table for out of range addresses.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/