Documentation About Device Driver Programming on Kernel 3.X

Documentation about device driver programming on kernel 3.x

There is no major difference between the last 2.6.x series kernel and the 3.x series. It's an arbitrary distinction.

The reference work for Linux device drivers is the aptly named Linux Device Drivers. It's somewhat out of date (being based on 2.6.10), but still a good guide. There are slightly less out-of-date examples on Martinez Javiers GitHub.

Of course, the ultimate guide is the code itself. Regardless of what you do you will have to refer to the code frequently. Code reading is an incredibly valuable skill, and you should practice it as much as possible.

Linux Kernel Programming Book for 3.x versions

There is not much difference between 2.6.32+ and 3.x in the basics how the kernel works. But yes, function names and APIs change from time to time. This is why books are already old once they are released. This is why I can recommend http://kernelnewbies.org/.

Similar questions have been answered already:

Documentation about device driver programming on kernel 3.x

Linux Device Drivers 3rd Ed and 3.2 kernel

The best documentation is the Linux kernel source itself as it changes so quickly. There are a lot of comments in the code and you should really check out the "Documentation" directory.

Wouldn't it be a good exercise to port the examples to more recent versions?

Very important is a list of changes to keep up with the mainline development: http://kernelnewbies.org/LinuxVersions

If they change the API, they also document the transition. Look at drivers doing similar things to what you want to achieve. How do they work? How did they react on API changes? ...

Subscribe to the related Linux kernel mailing lists and ask there for help for bigger issues from the active kernel developers.

Looking for an explanation of kernel driver I/O interface capability

What are these I/O ports that you're trying to access? It's generally a Really Bad Idea to go partying on ports that you don't own because you have no way of synchronizing access to those ports with the driver that owns them, the O/S, or the BIOS (it's possible to take an SMI and have the BIOS start talking to ports that it thinks it owns).

The code snippet provided is also a horribly bad idea and should be burned. Basically, all it's doing is mapping a kernel virtual address to a device register (MmMapIoSpace) and then doing the work to then map that device register into user mode (MmMapLockedPages). There are two obvious problems with it:

1) You don't know the caching attributes of the memory, so randomly specifying MmNonCached can hang the system

2) Same as with I/O ports, you can't just arbitrarily access a device's registers. You can't properly synchronize yourself with the driver that owns them, so you're doomed to eventually borking your system.

-scott

Which OS is the best for learning to write device drivers?

(a) Linux. Not only are there tutorials for how to write kernel modules and such, but you have the actual source of the kernel right there to look at. Windows might be decent as well.

(b) Linux. I'm not sure about OSX's docs, but if Apple is anything like they are with iOS, it might be a pain to get anything published. Windows, these days, IIRC you need a code signing certificate (to allow others to install it easily; no need to get a certificate for mere development).

(c) Most stuff has drivers for Windows and OSX. Linux is getting more and more support, but for any OS, there's nothing that says you can't write a driver for something that already has one. If your driver is better, people will recommend it -- hell, even the manufacturer of the device might want to include it on their CD. (Legalities abound there, though. watch yourself.)

How should i get started on Device Drivers

The very fist step is to download the WDK from Microsoft.

The WDK contains many sample drivers and an extensive documentation of the kernel API. Furthermore, the build environment and the compiler to use for drivers.

With this, you can choose which driver model to use, which api to follow ... etc.

A great source on the web is osronline with many articles and a community where to find answer for specific questions about driver development under windows.

---

To the specific question what your basic knowledge should be.

• Fluent knowledge of C
• Using build (makefile) systems
• Multithreading mutex/spinlock/concurrency
• Overall knowledge of OS principles (e.g. difference between virtual/physical memory, paging, message queues ...)
• Specific knowledge of the area you want to drill into. (E.g. register interface for USB devices/knowledge about filesystems/etc.)

(Not so much about hardware itself, because mostly windows hides low-level hardware details from you)

device driver documentation for linux

The command cat /proc/devices shows the character and block major device numbers in use by drivers in the currently running Linux kernel, but provides no information about minor device numbers.

There is a list of pre-assigned (reserved) device numbers in the Linux kernel user's and administrator's guide: Linux allocated devices (4.x+ version). (The same list also appears in "Documentation/admin-guide/devices.txt" in the Linux kernel sources.) The list shows how minor device numbers are interpreted for each pre-assigned character and block major device number.

Some major device numbers are reserved for local or experimental use, or for dynamic assignment:

  60-63 char    LOCAL/EXPERIMENTAL USE

  60-63 block   LOCAL/EXPERIMENTAL USE
        Allocated for local/experimental use.  For devices not
        assigned official numbers, these ranges should be
        used in order to avoid conflicting with future assignments.

 120-127 char   LOCAL/EXPERIMENTAL USE

 120-127 block  LOCAL/EXPERIMENTAL USE
        Allocated for local/experimental use.  For devices not
        assigned official numbers, these ranges should be
        used in order to avoid conflicting with future assignments.

 234-254    char    RESERVED FOR DYNAMIC ASSIGNMENT
        Character devices that request a dynamic allocation of major number will
        take numbers starting from 254 and downward.

 240-254 block  LOCAL/EXPERIMENTAL USE
        Allocated for local/experimental use.  For devices not
        assigned official numbers, these ranges should be
        used in order to avoid conflicting with future assignments.

 384-511 char   RESERVED FOR DYNAMIC ASSIGNMENT
        Character devices that request a dynamic allocation of major
        number will take numbers starting from 511 and downward,
        once the 234-254 range is full.

Character device drivers that call alloc_chrdev_region() to register a range of character device numbers will be assigned an unused major device number from the dynamic range. The same is true for character device drivers that call __register_chrdev() with the first argument (major) set to 0.

Some external ("out-of-tree") Linux kernel modules have a module parameter to allow their default major device number to be specified at module load time. That is useful for drivers that do not create their "/dev" entries dynamically, but want some flexibility for the system administrator to choose a major device number when creating device files manually with mknod.

Getting Started on Driver Development

One thing to beware of is the device driver development (architecture and tools) changes more than Win32 development ... so while Petzold's book from the 1990s is fine for Win32 and may be considered a timeless classic, the architecture for many kinds of drivers (printer drivers, network drivers, etc.) has varied in various O/S releases.

Here's a blog entry which reviews various books: Windows Device Drivers Book Reviews.

Don't forget the microsoft documentation included with the DDK: and, most importantly, the sample drivers (source code) included with the DDK. When I wanted to write a mock serial port driver, for example, I found the sample serial driver documentation combined with the DDK documentation was invaluable (and sufficient).

Is it possible to start working on an API for a hardware device before having the driver

Designing an API usually just means writing a C-language header file with the names of the methods your library provides, along with their arguments, return types, and any necessary documentation. So, yes, you can certainly start writing that file before you have a device driver.

Since you have two separate questions, I think you should have posted them separately on this site. But anyway, the answer to your second question depends heavily on what operating system you are using. In Windows, you would probably use DeviceIoControl and in Linux you would probably use ioctl (or just read and write).

---

Related Topics