What software were you building after the modification?
A lot of software is “user space”, and just an executable program. Other software is “kernel space”, meaning a kernel modification, either directly or via a kernel module (a kernel module is part of the kernel like any other code, but it can be loaded or unloaded at run time).
Often specialty software will need a certain kernel feature, which could be from a “.ko
” kernel module, or it could be from a new “/boot/Image
” (be careful working on the Image
, it could leave the system unbootable if done wrong), but a user space program might be required to use that kernel feature. Just as a contrived example, imagine you have support for hardware accelerated encryption…the kernel would support this, but it would be up to an end program to try to use the feature.
Regarding where modules go, the Image
searches for modules somewhere within:
/lib/modules/$(uname -r)/kernel
(copy and paste that as an argument to “cd
”, then run it and use “ls
” to see what is there)
The actual output of “uname -r
” is a combination of the base kernel version, plus the setting of “CONFIG_LOCALVERSION
” at the time of compile.
Notice that in the actual kernel source where a “.ko
” (module) is generated, there will be a path. Just as a contrived example, imagine your kernel source has subdirectory “drivers/net/usb/
”, and that you’ve just built a driver for a USB r8152 device. The module would be found (after built) at “drivers/net/usb/r8152.ko
”. Your final file copy would go to:
/lib/modules/$(uname -r)/kernel/drivers/net/usb/r8152.ko
After putting it there you could run “sudo depmod -a
”, and then any attempt to use that driver feature should find it and use it. You could also reboot.
I don’t know anything about any end user software or kernel feature for your specific case, the above is all just “in general”.
Note that if you are using some hardware using a specialized interface, then you might also need to adjust your device tree. Hot plug systems such as USB are able to self-describe so the driver can find it, but other specialized interfaces might need the device tree to tell the driver what address to point to. Basically, that device tree content could be passed to the driver you just added via the “.ko
” file (if and only if there is no automated method for the driver to find the hardware).