Just 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.
Thanks for submitting issue(s). The motivation of updating "The Linux Kernel Module Programming Guide" was for educational purpose. I agree with the idea to mention new kernel features such as Devicetree.
True. But there are some of us working on ARM platforms that aren't RPi that need to hack drivers.
Anyone working with a SOM, for example, will want to customize the DT for their carrier board. And then your EE finds a cheaper controller chip somewhere. And then your display supplier switches captouch parts on you mid-production.
Sorry, was I venting there?
(And just a tip, don't break bad on the Pi here. For many people this is the only ARM platform worth working with. And definitely don't make fun of the lack of peripherals on the thing)
Read the Documentation/devicetree directory in the kernel sources and look at how a few drivers implement their documented bindings.
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.
A semi-related question: do kernel modules play nicely with device-tree instantiations?
Like let's say I wanted to instantiate an I2C with a custom driver in my device-tree. Can I put the controller's driver in a kernel module that lives in /lib/modules? Or do I need to compile it into the kernel?
I just did that recently you can load a kernel module the driver will start working and the device will appear (if compatibility is setup correctly). You can remove the module and the device will stop and be removed from /dev.
yes ive done this recently with both spi and i2c. it works with modules, the hardest part for me was finding the right way to create the device tree so eg, my module got the spi bus over spidev. same with i2cdev if you are not using userspace
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.
There is (or can be) some overlap between the two.
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).
Yes, it'll work but device trees are still a little less dynamic than modules, which can be loaded and unloaded, and reconfigured at will. Device Trees still apparently have issues with dynamic reconfiguration. I think branches can be safely added, but removal is still problematic. This apparently is being worked on, so eventually it'll work, I understand.
In my opinion the best way to do kernel development is to just look at device drivers in kernel sources, study what current drivers do and write your own driver.
The kernel supports su much heterogeneous devices and its APIs change continuously that it is practically impossible to write a complete guide on this topic.
can 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.
Would I be out of line in suggesting DKMS to be used?
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.
Yeah, he needs to float his paragraph boxes so it can change text size when going from portrait to landscape (like rotating mobile device for better viewing).
https://github.com/sysprog21/lkmpg/releases # Alternatively, check the item "Assets", and you can get latest PDF file. I am looking for the feasible solutions to render LaTeX scripts in HTML.
Not 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.)
I am maintaining the content referred by the above hyperlink. At the moment, my students and I do not have sufficient understanding of publishing tools. Please check the PDF instead. https://github.com/sysprog21/lkmpg/releases
Just 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.
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
Thanks for submitting issue(s). The motivation of updating "The Linux Kernel Module Programming Guide" was for educational purpose. I agree with the idea to mention new kernel features such as Devicetree.
RPi is barely embedded work. It's almost always micro-desktop Linux.
True. But there are some of us working on ARM platforms that aren't RPi that need to hack drivers.
Anyone working with a SOM, for example, will want to customize the DT for their carrier board. And then your EE finds a cheaper controller chip somewhere. And then your display supplier switches captouch parts on you mid-production.
Sorry, was I venting there?
(And just a tip, don't break bad on the Pi here. For many people this is the only ARM platform worth working with. And definitely don't make fun of the lack of peripherals on the thing)
You're right. I was trying to write up a cpufreq driver for the Nintendo 3DS and found that LKMPG's complete lack of DT info astounding.
Which has nothing to do with RPi or embedded systems... Not sure if I understand.
Ugh... Cell phones? Or any of the zillion of ARM development boards out there.
Is there a guide for that?
Read the Documentation/devicetree directory in the kernel sources and look at how a few drivers implement their documented bindings.
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.
A semi-related question: do kernel modules play nicely with device-tree instantiations?
Like let's say I wanted to instantiate an I2C with a custom driver in my device-tree. Can I put the controller's driver in a kernel module that lives in /lib/modules? Or do I need to compile it into the kernel?
I just did that recently you can load a kernel module the driver will start working and the device will appear (if compatibility is setup correctly). You can remove the module and the device will stop and be removed from /dev.
yes ive done this recently with both spi and i2c. it works with modules, the hardest part for me was finding the right way to create the device tree so eg, my module got the spi bus over spidev. same with i2cdev if you are not using userspace
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).
There is (or can be) some overlap between the two.
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).
Yes, it'll work but device trees are still a little less dynamic than modules, which can be loaded and unloaded, and reconfigured at will. Device Trees still apparently have issues with dynamic reconfiguration. I think branches can be safely added, but removal is still problematic. This apparently is being worked on, so eventually it'll work, I understand.
In my opinion the best way to do kernel development is to just look at device drivers in kernel sources, study what current drivers do and write your own driver. The kernel supports su much heterogeneous devices and its APIs change continuously that it is practically impossible to write a complete guide on this topic.
Linux kernel code is extremely high quality too. I read it a lot. Very well structured.
can 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.
https://github.com/sysprog21/lkmpg/releases # Check the item "Assets", and you can get latest PDF and HTML files.
Using docker images is the preferable way to set up TeXLive and related packages. Please check the GitHub repository for details.
See also: https://0xax.gitbooks.io/linux-insides/
Would I be out of line in suggesting DKMS to be used?
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.
Tried 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.
Yeah, he needs to float his paragraph boxes so it can change text size when going from portrait to landscape (like rotating mobile device for better viewing).
https://github.com/sysprog21/lkmpg/releases # Alternatively, check the item "Assets", and you can get latest PDF file. I am looking for the feasible solutions to render LaTeX scripts in HTML.
Not 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`
I am maintaining the content referred by the above hyperlink. At the moment, my students and I do not have sufficient understanding of publishing tools. Please check the PDF instead. https://github.com/sysprog21/lkmpg/releases
The issue reported by mrmattyboy was resolved. You can now coy-n-paste from generated PDF and HTML files without annoying line numbers.