Open docbrown opened 8 years ago
I got a chance to look at this a little deeper and it appears the module loading code is pretty architecture-specific. Relocations have to be done differently depending on which architecture the ELF module was built for. I guess it will be easier to just build the driver along with the kernel.
Is this going to be implemented? Although module loading code is pretty architecture-specific, sometimes this still can be fixed ( in a hard way). This feature is useful for me as I have some kernel module which only supports kernel 3.10. I would like to try the module on my new machine.
@allientneko If you have the sources of the module you can stitch it in the kernel build, it is pretty easy to do.
Also related to #347
@tavip That's the problem. I do not have the source code. The company stops maintaining the module. However, I do agree that it may take a lot of effort to run the module even if LKL support this feather.
@allientneko Without source code it would be difficult to make the module work since that would require LKL to be compiled with the same options as the module, which might not be be even possible.
@tavip The only flags the module requires are SMP(Symmetric multiprocessing) and x64. The module symbol of the kernel module needs to be remapping to avoid "disagrees about version of symbol struct_module."
I tried it on UML. Almost there. However, UML does not support SMP. Hmm..... I should give up the obsolete kernel module and move on.
Is it possible to support loadable kernel modules in LKL and, if so, what sort of changes would have to be made to get that working? I would like to create a USB host controller driver that delegates to the host system's USB API and it would be great if I could test it without rebuilding and redeploying my entire application every time.