I figure it would be close to mandatory for anyone who wanted to distribute their module to others, without having to tell them to rebuild every time their kernel changed.
The Linux Kernel Module Programming Guide
21–30 of 32 posts
Re: The Linux Kernel Module Programming Guide
#22Re: The Linux Kernel Module Programming Guide
#23Tried to make text size larger at https://sysprog21.github.io/lkmpg/ and could not, it stays fixed. It would be great to fix this problem.
Re: The Linux Kernel Module Programming Guide
#24Just a warning if you do embedded work with Linux (RPi, Beaglebone, etc)... this guide doesn't cover the Devicetree APIs. Doesn't even acknowledge their existence.
> this guide doesn't cover the Devicetree APIs Is there a guide for that?
This isn't a snarky RTFM comment. The usage model file in the kernel documentation gives good motivation for what device trees are used for and their basic structure, and the APIs to pull data from them are straightforward enough that you can probably figure them out by looking at an example.
Re: The Linux Kernel Module Programming Guide
#25Earlier quoted context omitted.
Yep. The device tree and kernel modules are actually two seperate concepts - the former is just a data structure that describes the hardware for a system and the latter is a way of delivering the drivers independently of the kernel. Just make sure to run `depmod -a` after copying it into /lib/modules.
nice! I wasn't sure exactly how the ordering happens between (kernel loads the device-tree) and (kernel scans /lib/modules for stuff to autoload).
As an example, you may want to create a kernel module that can be configured through the device tree (e.g. binds to an arbitrary SPI/I2C bus, requires hardware-specific config). You can add a node for your module to the device tree and assign it a "compatible" property, which is just an arbitrary string you define to represent your module. If you then make your module export the same string using the MODULE_DEVICE_TABLE macro, the kernel will figure out that your module is the one that implements that node in the device tree, and it will call your module's probe callback to initialize the module, passing in the context from the device tree node (e.g. you can get a reference to the SPI/I2C bus hosting your device).
As I understand it, this is the standard way to implement drivers for devices that sit on buses that don't support automatic detection (e.g. not PCIe / USB).
Re: The Linux Kernel Module Programming Guide
#26This is awesome.. my only comment is the first thing I went to do was to copy and paste the code blocks and found end of line whitespace and double line breaks were included (presumably for the line numbering etc.)
e.g.
sudo apt-get update
apt-cache search linux-headers-`uname -r`
Re: The Linux Kernel Module Programming Guide
#27can you update the Makefile so it generate a PDF only? Also, the "make all" doesn't seems to be working as expected here. Probably missing some dependency.
Re: The Linux Kernel Module Programming Guide
#28Tried to make text size larger at https://sysprog21.github.io/lkmpg/ and could not, it stays fixed. It would be great to fix this problem.
Re: The Linux Kernel Module Programming Guide
#29Earlier quoted context omitted.
The author is pretty open to any kind of criticisms and suggestions. It would be great if you open an issue to inform him the missing contents.
Already did
Re: The Linux Kernel Module Programming Guide
#30Not sure if the eating555 is the author or whether the author is watching this thread... This is awesome.. my only comment is the first thing I went to do was to copy and paste the code blocks and found end of line whitespace and double line breaks were included (presumably for the line numbering etc.) e.g. sudo apt-get update apt-cache search linux-headers-`uname -r`