Hi, I have two kernel modules that need to talk over an API, and right now, they are statically linked together, but I am looking for a better way to separate them and share an API between them. A few years ago, I did the HDA component: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/sou... Using the component API: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/inc... Are there other ways for a module to wait for another module to load and use its API? Is there a default way to do that? I know that with MFD devices, you can have children, but that's not the case. My modules are not related in that way. Thanks Lucas
On Thu, May 18, 2023 at 08:16:18AM +0100, Lucas Tanure wrote:
Hi,
I have two kernel modules that need to talk over an API, and right now, they are statically linked together, but I am looking for a better way to separate them and share an API between them.
A few years ago, I did the HDA component: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/sou...
Using the component API: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/inc...
Are there other ways for a module to wait for another module to load and use its API? Is there a default way to do that?
Yes, just call a function in that other module and it will be loaded properly before your module can call it. That's how all in-kernel apis work. thanks, greg k-h
On Thu, May 18, 2023 at 08:16:18AM +0100, Lucas Tanure wrote:
Are there other ways for a module to wait for another module to load and use its API? Is there a default way to do that? Hi Lucas, IIUC you can use MODULE_SOFTDEP macro to establish loading dependencies. This stack overflow explains it:- https://stackoverflow.com/questions/29717761/how-do-i-define-dependency-amon...
Prathu
Hi, I have been working with Kernel development and single-board computers for a few years now, and to help me with my development, I created this tool: https://github.com/lucastanure/kernel_dev_tools (GPLv2) It helps me to build and test the kernel in a faster and easy way. But it also helps me to switch between boards (Rpi4, Vim4, Vim3, rk399) in a reliable way. The aim of this tool is to centralize the configuration of a particular board (cross-compiler, kernel configuration, make targets, etc.) in a config file and expose a simple workflow. Example: I have my VIM4 board configuration: [vim4_arm64] cc = aarch64-none-linux-gnu- cc_path = ~/.local/bin/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/bin kernel_target = Image kernel_file = Image-devel dtb_path = dtbs_devel config_file = $kdt_boards/vim4_arm64_defconfig ramfs_file = initramfs-linux-devel.img update_ramfs = mkinitcpio -k $version -g $ramfs_file on = kasa --alias Strip_9BA6 --type strip on --name P2 off = kasa --alias Strip_9BA6 --type strip off --name P2 And my workflow to develop the kernel is as follows: $ export board=vim4 # Do some kernel changes $ kb config # Configures the kernel $ kb build # Builds the kernel $ kb scp vim4 # Copy the kernel, modules and device trees to my VIM4 board using rsync and scp # Reboot the board using ssh or issue: $ kb off ; sleep 2 ; kb on # Power cycle the board if reboot by ssh is not available This tool has many more features, like updating kernels in image files and removing Gerrit "Change-id" from patch files. In the near future, I will add the following: - Check a series of patches before upstreaming. Build the kernel with every patch in a patch series and check for building warnings, checkpatch, sparse, etc. - Device tree tool to help to upstream new boards to the kernel mainline. Like, find device nodes from a device tree that don't have a driver for it and list Kernel configs needed by the device tree. Happy coding Thanks Lucas
participants (3)
-
Greg KH -
Lucas Tanure -
Prathu Baronia