A kernel module(.ko) is a bit of compiled code that can be inserted into the kernel at run-time, such as with insmod or modprobe. A driver is a bit of code that runs in the kernel to talk to some hardware device. It "drives" the hardware. Most every bit of hardware in your computer has an associated driver. A large part of a running kernel is driver code; the rest of the code provides generic services like memory management, IPC, scheduling, etc.
A driver may be built statically into the kernel file on disk. (The one in /boot, loaded into RAM at boot time by the boot loader early in the boot process.) A driver may also be built as a kernel module so that it can be dynamically loaded later. (And then maybe unloaded.)
Standard practice is to build drivers as kernel modules where possible, rather than link them statically to the kernel, since that gives more flexibility. There are good reasons not to, however:
Linux Header packages only contain the header part of the above (and not all of that - only the "exported" headers), and some of the build infrastructure. So what you are seeing is expected. Header packages do not contain C source code (except for some stubs and build infrastructure code). The whole point of having this type of package is to save space (and bandwidth) - the whole Linux kernel source tree is rather large, and completely unnecessary if you don't intend to compile the kernel yourself. The header packages are built and shipped by distributions to provide just the right things necessary to build modules, but no more. (They certainly do not contain the compiled kernel.)
Installed linux kernel binaries are usually installed in the /boot directory, along with bootloader binaries and configuration files. (This is sometimes an independent filesystem, not mounted by default.) The exact name of the files depends on the kernel and distribution. (So does the bootloader.)
Kernel newbies - http://kernelnewbies.org/
Kernel coverage at LWN.net - http://lwn.net/Kernel/
Linux kernel documentation(all in one) - https://code.google.com/p/kernel-all-in-one/source/browse/trunk/Docs/?r=70
Unreliable Guide To Hacking The Linux Kernel - http://kernelbook.sourceforge.net/kernel-hacking.pdf
Linux kernel development 3rd edition by Robert Love - https://archive.org/details/pdfy-PjVB7QjMXCW8xzZj, http://reiber.org/nxt/pub/Linux/LinuxKernelDevelopment/Linux.Kernel.Development.3rd.Edition.pdf
Linux Device drivers 3rd edition - http://lwn.net/Kernel/LDD3/
Understanding the Linux Kernel, 3rd Edition By Daniel P. Bovet, Marco Cesati - http://gauss.ececs.uc.edu/Courses/c4029/code/memory/understanding.pdf
The Linux Kernel Module Programming Guide - http://www.tldp.org/LDP/lkmpg/2.6/lkmpg.pdf
Linux kernel in a Nutshell - https://aligunduz.org/random/LinuxKernelInANutshell.pdf, http://www.kroah.com/lkn/
Linux Device Driver Dos and Don'ts - http://kernel-janitor.sourceforge.net/kernel-janitor/docs/driver-howto.html
Kernel APIs, Part 1: Invoking user-space applications from the kernel - http://www.ibm.com/developerworks/library/l-user-space-apps/
A driver may be built statically into the kernel file on disk. (The one in /boot, loaded into RAM at boot time by the boot loader early in the boot process.) A driver may also be built as a kernel module so that it can be dynamically loaded later. (And then maybe unloaded.)
Standard practice is to build drivers as kernel modules where possible, rather than link them statically to the kernel, since that gives more flexibility. There are good reasons not to, however:
- Sometimes a given driver is absolutely necessary to help the system boot up. That doesn't happen as often as you might imagine, due to the initrd feature.
- Statically built drivers may be exactly what you want in a system that is statically scoped, such as an embedded system. That is to say, if you know in advance exactly which drivers will always be needed and that this will never change, you have a good reason not to bother with dynamic kernel modules.
Linux Header packages only contain the header part of the above (and not all of that - only the "exported" headers), and some of the build infrastructure. So what you are seeing is expected. Header packages do not contain C source code (except for some stubs and build infrastructure code). The whole point of having this type of package is to save space (and bandwidth) - the whole Linux kernel source tree is rather large, and completely unnecessary if you don't intend to compile the kernel yourself. The header packages are built and shipped by distributions to provide just the right things necessary to build modules, but no more. (They certainly do not contain the compiled kernel.)
Installed linux kernel binaries are usually installed in the /boot directory, along with bootloader binaries and configuration files. (This is sometimes an independent filesystem, not mounted by default.) The exact name of the files depends on the kernel and distribution. (So does the bootloader.)
Installed linux kernel modules reside in sub-directories /lib/modules/`uname -r`/
Full kernel source code: /usr/src/linux is a traditional place to put kernel sources, but nothing prevents you from putting kernel sources elsewhere. This path is also often just a symbolic link to a directory. The symlink is there to simplify building applications that depend on the kernel source. KConfig files are a description of the kernel configuration options (and their dependencies) that are available for a given directory/module. Apart from that, it's all (mostly) C source code, header files and Makefiles. There are a few helper scripts here and there, and assembly source too.
Linux device drivers commands:
- Know the linux kernel version from kernel source code =>
- make kernelversion
- Check the top-level Makefile contents
- Miscellaneous commands
Linux command syntax
|
Linux command description
|
ls -R /lib/modules/$(uname -r)
|
Command to list all modules available for a given linux system
|
modinfo /path/to/module.ko
|
Display module information
|
insmod kernel-module-name
|
Install a module to a running kernel. NOTE: this command does not resolve module dependencies
|
modprobe kernel-module-name
|
Install a module to a running kernel inlcuding dependencies
|
depmod -a
|
Rebuild module dependancy database using /lib/modules/$(uname -r)/modules.dep
|
insmod --force kernel-module-name
|
Force insmod to load module even if its build for a defferent module version
|
modprobe -n -v kernel-module-name
|
Display insmod commands to load module and its dependencies. Useful when modprobe gives up due to dependency problem
|
lsmod
|
Display all modules currently loaded into a kernel
|
rmmod kernel-module-name
|
Command to remove a module from a running kernel
|
General linux commands:
- list all the dependent libraries of a binary => ldd $$(NAME_OF_BINARY)
- list all API exposed by shared library =>
- nm –D –defined-only name_of_binary (Exported sumbols are indicated by a T. Required symbols that must be loaded from other shared objects have a U)
- objdump –T $(NAME_OF_BINARY)
- find the bitness of a file =>
- readelf –h $(NAME_OF_BINARY)
- objdump –a $(NAME_OF_BINARY)
- Print CRC checksum and byte counts of each file => cksum
- Print MD5 hash sum of a file => md5sum
- Print SHA1 hash sum of a file => sha1sum
- Estimate file space usage => du –h $(NAME_OF_DIRECTORY)
- Display amount of free and used memory in the system(in mega bytes) => free -m
- Find the process ID of a running program => pidof
- Outputs file status => stat
- Print the strings of printable characters in files => strings
- Locate the binary, source, and manual page files for a command => whereis
- Display a tree of processes => pstree
ref:
Linux kernel documentation(all in one) - https://code.google.com/p/kernel-all-in-one/source/browse/trunk/Docs/?r=70
Unreliable Guide To Hacking The Linux Kernel - http://kernelbook.sourceforge.net/kernel-hacking.pdf
Linux kernel development 3rd edition by Robert Love - https://archive.org/details/pdfy-PjVB7QjMXCW8xzZj, http://reiber.org/nxt/pub/Linux/LinuxKernelDevelopment/Linux.Kernel.Development.3rd.Edition.pdf
Linux Device drivers 3rd edition - http://lwn.net/Kernel/LDD3/
Understanding the Linux Kernel, 3rd Edition By Daniel P. Bovet, Marco Cesati - http://gauss.ececs.uc.edu/Courses/c4029/code/memory/understanding.pdf
The Linux Kernel Module Programming Guide - http://www.tldp.org/LDP/lkmpg/2.6/lkmpg.pdf
Linux kernel in a Nutshell - https://aligunduz.org/random/LinuxKernelInANutshell.pdf, http://www.kroah.com/lkn/
Linux Device Driver Dos and Don'ts - http://kernel-janitor.sourceforge.net/kernel-janitor/docs/driver-howto.html
Kernel APIs, Part 1: Invoking user-space applications from the kernel - http://www.ibm.com/developerworks/library/l-user-space-apps/