Hello, Keith
Thank you for the comment.
> 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.
It is necessary to use kernel_data field in struct module. I see.
> 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.
Certainly, I made patch for the x86 architecture.
However, I guessed that neither creation nor free of profiling buffer
would depend on architecture.
And, I had it write these processing (create_module_profile(),
delete_module_profile()) in kernel/profile.c, and call from module().
Isn't this idea correct?
If it is not correct, it is necessary to inpriment as processing of
the architecture dependence like your point it.
>
> 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.
It is so. Processing which specifies module from eip is corrected as
shown in the point.
-- hirao <hirao@estartu.open.nm.fujitsu.co.jp>- 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/
This archive was generated by hypermail 2b29 : Sun Mar 31 2002 - 22:00:08 EST