Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Linux Kernel Module Programming Guide

github.com

Post reply on HN
Print view View original

11–20 of 32 posts

Re: The Linux Kernel Module Programming Guide

#11

Post by csoete »

nrclark wrote: post #7

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.

Re: The Linux Kernel Module Programming Guide

#12

Post by dexterhaslem »

nrclark wrote: post #7

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?

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

Re: The Linux Kernel Module Programming Guide

#13

Post by ndesaulniers »

joezydeco wrote: post #8
tajustice1 wrote: post #6

Earlier quoted context omitted.

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 pe…

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.

Re: The Linux Kernel Module Programming Guide

#14

Post by tajustice1 »

joezydeco wrote: post #8
tajustice1 wrote: post #6

Earlier quoted context omitted.

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 pe…

>True. But there are some of us working on ARM platforms that aren't RPi that need to hack drivers.

Which has nothing to do with RPi or embedded systems... Not sure if I understand.

>And just a tip, don't break bad on the Pi here. For many people this is the only ARM platform worth working with.

Ugh... Cell phones? Or any of the zillion of ARM development boards out there.

Re: The Linux Kernel Module Programming Guide

#15

Post by allo37 »

nrclark wrote: post #7

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?

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.

Re: The Linux Kernel Module Programming Guide

#16

Post by nrclark »

allo37 wrote: post #15
nrclark wrote: post #7

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?

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).

Re: The Linux Kernel Module Programming Guide

#17

Post by matheusmoreira »

joezydeco wrote: post #2

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.

> this guide doesn't cover the Devicetree APIs

Is there a guide for that?

Re: The Linux Kernel Module Programming Guide

#18

Post by matheusmoreira »

fmntf wrote: post #9

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.

Re: The Linux Kernel Module Programming Guide

#19

Post by pklo »

nrclark wrote: post #7

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?

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.
Post reply on HN