On 14/03/16 10:55, Jan Kiszka wrote: > On 2016-03-14 11:48, Kieran Bingham wrote: >> On 14/03/16 10:36, Jan Kiszka wrote: >>> Hi Kieran, >>> >>> On 2016-03-14 11:20, Kieran Bingham wrote: >>>> Hi Jan, >>>> >>>> Whilst testing the modules update patch you sent, I discovered (due to >>>> having rebased to v4.5) that the module search path will end up picking >>>> an incorrect version of the .ko file if an earlier version exists.: >>>> >>>> >>>> (gdb) lx-symbols /opt/root/ubuntu-vivid.x86_64 >>>> loading vmlinux >>>> (gdb) c >>>> Continuing. >>>> < load module helloworld.ko on target > >>>> scanning for modules in /opt/root/ubuntu-vivid.x86_64 >>>> loading @0xffffffffa0000000: >>>> /opt/root/ubuntu-vivid.x86_64/lib/modules/4.4.0+/extra/helloworld.ko >>>> >>>> Looking at the filesystem layout: >>>> >>>> kbingham@CookieMonster:~$ sudo find /opt/root/ubuntu-vivid.x86_64/ -name >>>> helloworld.ko >>>> /opt/root/ubuntu-vivid.x86_64/lib/modules/4.4.0+/extra/helloworld.ko >>>> /opt/root/ubuntu-vivid.x86_64/lib/modules/4.5.0+/extra/helloworld.ko >>>> >>> >>> If there are multiple sets of modules underneath a path, you have to be >>> more precise, /opt/root/ubuntu-vivid.x86_64/lib/modules/4.5.0+ in this case. >>> >>>> >>>> Unfortunately I can't see any reference to a vfs path in: >>>> print $lx_module("helloworld") >>>> >>>> So we can't retrieve the exact path location from the kernel information >>>> Have you experienced this issue? >>> >>> No, because I'm always using lx-symbols against the build output, not >>> against installed modules. But even then, see above, I don't see a >>> problem is the path is properly specified. >>> >> >> Ok, I see. I guess it's just a different use-case. ST had this factored >> out so that the user did not have to do much other than specify the root >> path. And in fact, the 'user' didn't do this as it was pre-set. >> >> I had even toyed with the idea that we could parse the commandline - and >> if we detect an nfsroot, automatically provide that on the search path. >> >> Perhaps we'll put this on the to-think-about stack for now then on this >> side :) >> >> Specifying the full path to modules isn't an unreasonable solution IMO, >> so it will just come down to a user-experience thing. The automatic >> detection could just be classed as a nice feature for the future perhaps. > > If you wanna do version matching, you could parse the module header and > filter out everything that's incompatible. But then I'm afraid of the > loading time...
Interesting alternative. I guess this parsing would only occur on files after a filename match, so I don't see it as being too intrusive. Perhaps something to test and measure later, and would need testing on a large number of modules (with a large number of false positives to match against). -- Kieran > > Jan >