Zhang, Xiantao wrote: >>>> That answer confuses me. kvm_arch_init() for ia64 will reside in >>>> kvm.ko just like kvm_init(), right? >>>> So THIS_MODULE will be the same in kvm_arch_init() and kvm_init(). >>>> So which module are you giving as argument? >>>> >>>> >>> Sorry for confusing you. In KVM/IA64 architecture, we have a separate >>> module called vmm module to handle mmu and cpu virtualization. It is >>> not related to kvm_arch, and will be relocated by kvm.ko when it is >>> initilized. So, we have to get some information through its >>> registeration when it calls kvm_init. Certaninly, this information >>> should be transftered to kvm_arch_init, and handled by ia64-specific >>> code. Is it clear now? >>> >>> >> Can it not just call an ia64 specific function? >> >> >> Is it actually required to be a kernel module? (is it linked with the >> rest of the kernel?) If not, maybe it can be a .o file instead of a >> .ko, and loaded via the request_firmware() mechanism. >> > > Hi Avi, > Thanks, But seems it is very hard to implement it through a.o, > because all functions in this part should be relocated to another > separate address space in whole. If it is implemented as a module(ko), > we can relocate it as a whole. Currenlty, we haven't found an easy > method to handle it, due to IA64 virtualization architecture's > intrinsic implementation. Anyway, adding one arg in this function > shouldn't impact other architectures. What's your opinion? :) > Xiantao >
I can't say much about .o vs .ko without further information. Regarding passing the module parameter, you might have your module call some function that is only present in the ia64 implementation to register itself, instead of calling common code (or, you can have the ia64 code call some function in your vmm module to get information from it). -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
