Apparently, modules (loadable and built-in) are stored in the
/lib/modules/$(uname -r)/modules.builtin
directory. According to different topics, you need to recompile the kernel if you want to change a built in module. I would like to know what would happen if I replaced a .ko module in the
/lib/modules/$(uname -r)/modules.builtin
directory.
Thank you.
Related
I am creating a cmake package config file (a Foo-config.cmake) for a pre-existing .dll not created by cmake.
The annoying thing is that the .dll depends on some data files.
When a user consumes my package in his own cmake project, I want the INSTALL target to install both the .dll and data files to his specified install location. I don't want him to have to write extra install() rules to do that.
Is it good practice to write the install() rules directly in my Foo-config.cmake? Or is there a better way to do this, maybe with set_target_properties()? I just couldn't find the appropriate property for associating arbitrary file dependencies to a target.
In an alternate universe where this .dll didn't already exist and I had to create it myself using cmake, would I need to create a custom Foo-config.cmake, or is there something in cmake that can automatically generate it for me to achieve the same thing?
FWIW the .dll is an internal legacy library and is normally built by Visual Studio and uploaded in a .zip file to our internal artifactory. I want us to migrate away from manually pulling down .zip files from artifactory and manually integrating the files into Visual Studio projects.
I've since found that there are a couple different ways to do this:
In the config file, simply create one or more variables for the files/dirs you want to install. Then install those using install(FILES) and/or install(DIRECTORY). More info: https://stackoverflow.com/a/46361538/189341
Use file(GET_RUNTIME_DEPENDENCIES). More info:
https://discourse.cmake.org/t/installing-a-pre-built-module-and-its-various-dependencies/5227
How to use cmake file( GET_RUNTIME_DEPENDENCIES in an install statement?
Is it good practice to write the install() rules directly in my Foo-config.cmake?
No.
From 480 *-config.cmake and *Config.cmake files on my system none calls install().
Or is there a better way to do this, maybe with set_target_properties()?
No.
In an alternate universe where this .dll didn't already exist and I had to create it myself using cmake, would I need to create a custom Foo-config.cmake
No. This is unrelated to if you create a .dll or not. If .dll exists, there is no need to create Foo-config.cmake anyway. It is your choice that you want to (or make users to) use find_package.
is there something in cmake that can automatically generate it for me
No.
If you don't intent to support find_package features - VERSION OPTIONAL_COMPONENTS PATHS HINTS CONFIGS etc. - then just go with include(). find_package is just include() with some extra options.
If you want to have install() in your find_package, then just protect it with a variable, like if (FOO_DO_INSTALL) install(....) endif().
I use cmake to install a linux driver. To get the kernel version I use CMAKE_SYSTEM_VERSION which should yield the output of uname -r.
However, after I installed a new kernel, I tried to reinstall the driver with cmake, just to note that it was installing to /lib/modules/<previous kernel>/... rather than to the directory for the current kernel. uname- r gives the correct result.
I use the following line in my CMakeLists.txt:
install(PROGRAMS myDevice.ko DESTINATION "/lib/modules/${CMAKE_SYSTEM_VERSION}/kernel/drivers/myDevice" COMPONENT driver)
I could not find CMAKE_SYSTEM_VERSION in the CMakeCache.txt, and just rerunning cmake .. did not do the trick either. I had to regenerate the entire build folder.
I would like to know if there is a better way, since the build folder also contains applications, that should not need rebuilding, just because there is a new kernel.
There are CMake variables, which are fixed since the first configuration. CMAKE_SYSTEM_VERSION is one of them. CMAKE_C_COMPILER is another example of "fixed" variables: changing it invalidates cache completely.
So, you need to make different builds for different kernels.
You may separate configuration and building of user-space application from kernel modules. So rebuilding kernel module doesn't force rebuilding of the applications.
Exactly that approach I have used in my projects: setting one option (introduced with option() command) builds only applications, setting another option builds only kernel modules. By default, none option is set and both kernel-space and user-space components are built.
I'm using buildroot to create a linux system for raspberry pi. I want to use the initramfs to enable to system to self-patch. The procedure roughly runs as follows:
Raspi boots, kernel loads initramfs
The initramfs-system (which contains busybox, zsync etc.) connects to a central server and checks if there are boot-file updates available (e.g. a new kernel)
If not, it checks if there is a system update available and downloads that if needed
The downloaded (squashfs) system image is mounted and executed via switch_root
My problem is that I need to compile a secondary busybox (and some more packages) for the initramfs which do not belong in the main system. I currently solved this by manually tinkering with the package files to install into target/initramfs, moving this folder out with pre-build and back in again with post-build, but this seems rather hacky. Additionally, different package types require different types of changes. Is there a better solution to this problem? If one could for example manually overwrite the target directory for each package, this problem would be rather easy to solve.
Create two separate buildroot configurations.
One configuration will have the kernel and the initramfs.
The other configuration only has the squashfs rootfs.
Creating a partial rootfs from a configuration is very tricky, because you have to be sure that you don't miss any shared libraries or other auxiliary files needed by some program.
Note that to speed up the build, you can use ccache and/or use an external toolchain. See the manual.
Is it possible to load a specific package during runtime?
I want to have a kind of plugins where each one has the same functions than the others but with different behaviour, and depending on the configuration file, load one or other.
No, Go doesn't support dynamically loaded libraries.
Your best bet is to start the plugin as its own executable and communicate with it through sockets or via stdin/stdout.
2017 update
This answer is no longer true, Go now supports plugins (for Linux and MacOS only as of June 2021)
There is support for this now as of go 1.8
https://golang.org/pkg/plugin/
You might consider executing the ‘plugin’ packages at runtime, by writing out a new program (say, to a temp directory) and executing via exec.Command, something along the lines of exec.Command("go", "run", files…).Run()
You’ll see some similar code here.
Just do these,create a codegen that reads the configuration, generates a basic go file with the packages loaded in order and then execute that, compile languages won't nor provide dynamic loading, even dart suffers in a way,simple just read your configuration file then create a temporary file with the necessary codes to load up and communicate with sockets or http
I think what you are looking for is the special function init
if you add a
func init() {
}
inside a package it will run it the first time the package is imported.
This happens only in the same binary. As other have already said go does not support dynamically loaded libraries.
I am working on a project that is using Leopardboard DM368 interfacing with LI-M024DUAL camera board for stereo vision. The camera uses Aptina's MT09M024 as its image sensor.
After spending a lot of time on the web searching for appropriate drivers I asked the OEM to provide me some support. They provided me with the driver source files. The problem is I am not able to include them to the kernel.
I also looked up for the method to build modules and am fairly comfortable with it. But with the current driver I have a bunch of *.c files that use non-existent header files (I am not able to find these linux header files in the /linux directory).
Now my question is if I have the source code for an image sensor driver and want to build it, what is the general procedure followed for the same.
Any help in this regard would be welcome.
-Kartik
There are two ways to build you module:
1. Statically linking to kernel image (inbuilt)
2. Creating dynamically loadable Modules
Statically linking to kernel image (inbuilt)
For this you must find a appropriate place in kernel folder (somewhere in drivers/) to copy your .c files. copy them there. Edit Kconfig and Makefiles refering to other kernel drivers. and enable the support using menuconfig. Compile.
Creating dynamically loadable Modules
You can built without copying them to Kernel source. Just create a Makefile and place rules in Makefile to compile your module. Here you must link your module to your kernel by providing the kernel source path.
For more google should help.