Linux Device Drivers: Tutorial for Linux Driver Development

Key takeaways:

• Building a reliable device driver is key to seamless communication between the Linux operating system and hardware.
• Linux drivers are typically developed through the loadable kernel module approach, enabling quick integration and updates without kernel recompilation.
• This hands-on example provides a solid foundation for creating a fully functional Linux device driver.
• For maximum stability and security, partner with Apriorit — a trusted expert in driver development.

Linux device drivers serve as a critical link between the operating system and hardware, making their reliability and performance essential for overall Linux system stability. So, how can you ensure this stability right from the development stage?

Building a Linux device driver demands in-depth knowledge of the operating system’s internals. Apart from understanding kernel architecture and memory management, your team also needs to have strong expertise in driver programming.

In this tutorial, Apriorit experts provide you with step-by-step instructions on how to build a driver in Linux (starting from kernel version 6.14.0), including code samples.

You’ll get insights on:

• Kernel logging
• Principles of working with kernel modules
• Character devices
• The file_operations structure
• Accessing user-level memory from the kernel

You’ll also find source code for a simple Linux driver that you can augment with any functionality you need.

This article will be useful for development teams involved in Linux device driver programming, as well as CTOs and heads of engineering who are looking for vendors with deep expertise in driver development.

Getting started with the Linux kernel module

The Linux kernel is written in the C and Assembler programming languages. C implements the main part of the kernel, while Assembler implements architecture-dependent parts. In the past, it was only possible to use these two languages for Linux kernel development. Starting from Linux version 6.1, you can also use Rust ​. However, since Rust support in the Linux kernel is still in the active development phase, in this article, we will focus on C. 

Note that you can’t use C++ as you can with the Windows kernel, as some parts of the Linux kernel source code (such as header files) may include keywords from C++ (for example, delete or new), while in Assembler, you may encounter lexemes such as ‘ :: ’.

There are two ways of writing device drivers in Linux:

1. Compile the driver along with the kernel, which is monolithic in Linux — this is the traditional approach.
2. Implement the driver as a kernel module, in which case you won’t need to recompile the kernel.

The second approach is more efficient and flexible than the traditional one. Instead of recompiling the entire kernel, developers can create loadable kernel modules (LKMs) containing device driver code. You can load LKMs into the kernel dynamically at runtime without requiring a system reboot.

In this tutorial, we’ll develop a device driver in the form of a kernel module. A module is a specifically designed object file. When working with modules, Linux links them to the kernel by loading them into the kernel address space. 

Module code operates in the kernel context. This requires developers to be very attentive. If a developer makes a mistake when implementing a user-level application, in most cases, it won’t cause problems outside the user application. But mistakes in the implementation of a kernel module can lead to system-level issues.

Luckily for us, the Linux kernel is resistant to non-critical errors in module code. When the kernel encounters such errors (for example, null pointer dereferencing), it displays the oops message — an indicator of insignificant malfunctions during Linux operation. After that, the malfunctioning module is unloaded, allowing the kernel and other modules to work as usual. In addition, you can analyze logs that precisely describe non-critical errors. Keep in mind that continuing driver execution after an oops message may lead to instability and kernel panic.

The kernel and its modules represent a single program module and use a single global namespace. In order to minimize the namespace, you must control what’s exported by the module. Exported global characters must have unique names and be cut to the bare minimum. A commonly used workaround is to simply use the name of the module that’s exporting the characters as the prefix for a global character name.

With this basic information in mind, let’s proceed to writing Linux device drivers.

Creating a kernel module

You can start by creating a simple prototype of a kernel module that can be loaded and unloaded. Let’s do that with the following code:

#include <linux/init.h>
#include <linux/module.h>


MODULE_DESCRIPTION("Simple Linux driver");
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Apriorit, Inc");


static int simple_driver_init(void)
{
   return 0;
}


static void simple_driver_exit(void)
{
   return;
}


module_init(simple_driver_init);
module_exit(simple_driver_exit);

#include <linux/init.h>
#include <linux/module.h>


MODULE_DESCRIPTION("Simple Linux driver");
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Apriorit, Inc");


static int simple_driver_init(void)
{
   return 0;
}


static void simple_driver_exit(void)
{
   return;
}


module_init(simple_driver_init);
module_exit(simple_driver_exit);

Where:

• The simple_driver_init function is the driver initialization entry point and is called during system startup (if the driver is statically compiled into the kernel) or when the module is loaded into the kernel.
• The simple_driver_exit function is the driver exit point. It is called when unloading a module from the Linux kernel. This function has no effect if the driver is statically compiled into the kernel.

These functions are declared in the linux/module.h header file. The simple_driver_init and simple_driver_exit functions must have identical signatures, such as these:

int init(void);
void exit(void);

int init(void);
void exit(void);

Now, our simple module is complete. Let’s make it log in to the kernel and interact with device files. These operations will be useful for Linux kernel driver development.

Registering a character device

Note: In this tutorial, we describe how to create a character device (with a corresponding character device file) that doesn’t require any additional command execution in the Linux terminal (such as the mknod command in the basic solutions).

Device files are usually stored in the /dev folder. They facilitate interactions between the user space and kernel code. To make the kernel receive user-space data, you can write this data to a device file and pass it to the module serving this file. User-space data that’s read from a device file originates from the module serving it.

There are two groups of devices: 

1. Character devices — character device files are non-buffered and allow you to read and write data character by character. We’ll focus on this type of file in this tutorial.
2. Block devices — block device files are buffered and allow you to read and write only whole blocks of data.

Linux systems have two ways of identifying device files:

1. Major device numbers identify modules serving device files or groups of devices.
2. Minor device numbers identify specific device files among a group of devices specified by a major device number.

You can define these numbers in the driver code, or they can be allocated dynamically by the kernel. If a number defined as a constant has already been used, the system will return an error. When a number is allocated dynamically, the function reserves that number to prevent other device files from using the same number.

To create and register a character device, you need to perform a few steps:

1. Allocate a character device region (if you want to allocate a major device number dynamically) or register one (if you want to use a predefined major device number).
2. Add a character device to the system.
3. Create a device class and register a character device file.

Let’s explore these steps in detail. 

1. Allocate a character device region

To allocate a character device region, you need to use the alloc_chrdev_region function:

int alloc_chrdev_region(dev_t *dev, unsigned baseminor, unsigned count,
                       const char *name)

int alloc_chrdev_region(dev_t *dev, unsigned baseminor, unsigned count,
                       const char *name)

Here, we specify:

• The pointer to the device number. This is the result device number (combination of major and minor numbers) after the function call. In our case, we use a global variable to keep the received device number available for different parts of our driver.
• The first requested number from the requested range of minor numbers. If you’re not sure about this parameter, you may specify 0.
• The number of required minor numbers. You may need more than one allocated minor number (for example, a few minor numbers may be required for one device, or a few separated devices may require one minor number each). But for one simple character device, it’s enough to have one allocated minor number.
• The name of the associated device or driver. You may use the name of your module or another name. This name will be related to the allocated range of device numbers, but it won’t be used as the device file name in the /dev folder.

2. Add a character device to the system

To add a character device to the system, you need to initialize the representation of the character device in the kernel module — an instance of the cdev structure. Here’s how it looks:

struct cdev
{
   struct kobject kobj;
   struct module *owner;
   const struct file_operations *ops;
   struct list_head list;
   dev_t dev;
   unsigned int count;
} __randomize_layout;

struct cdev
{
   struct kobject kobj;
   struct module *owner;
   const struct file_operations *ops;
   struct list_head list;
   dev_t dev;
   unsigned int count;
} __randomize_layout;

This instance will be declared as a static variable to keep it available for different parts of our driver. If you don’t understand the instance’s fields to initialize them correctly, you can use a helper for cdev structure initialization:

void cdev_init(struct cdev *cdev, const struct file_operations *fops)

void cdev_init(struct cdev *cdev, const struct file_operations *fops)

For initialization, this helper requires only one additional parameter — a pointer to the file_operations structure, which we’ll discuss later.

When the cdev instance is initialized, you may add it to the system using the following function:

int cdev_add(struct cdev *p, dev_t dev, unsigned count);

int cdev_add(struct cdev *p, dev_t dev, unsigned count);

This function requires two parameters, in addition to the cdev instance:

• The device number (received from alloc_chrdev_region)
• The number of minor numbers that will be associated with this device (in our case, 1)

At this step, basic registration of the device in the system is finished. There are currently no device files in the system, but they can be created using console commands. In our example, we’ll use an alternative approach that, from our perspective, is more convenient for real-world products: creating device files from the driver code. But before proceeding with this functionality, let’s take a look at the file_operations structure used.

file_operations structure

The file_operations structure contains pointers to the functions that will be called to handle specified operations performed on the character device file. For example, it may involve writing to or reading from our character device file. 

In the Linux 6.14.0 kernel, the file_operations structure looks like this:

struct file_operations
{
   struct module *owner;
   fop_flags_t fop_flags;
   loff_t (*llseek)(struct file *, loff_t, int);
   ssize_t (*read)(struct file *, char __user *, size_t, loff_t *);
   ssize_t (*write)(struct file *, const char __user *, size_t, loff_t *);
   ssize_t (*read_iter)(struct kiocb *, struct iov_iter *);
   ssize_t (*write_iter)(struct kiocb *, struct iov_iter *);
   int (*iopoll)(struct kiocb *kiocb, struct io_comp_batch *,
                 unsigned int flags);
   int (*iterate_shared)(struct file *, struct dir_context *);
   __poll_t (*poll)(struct file *, struct poll_table_struct *);
   long (*unlocked_ioctl)(struct file *, unsigned int, unsigned long);
   long (*compat_ioctl)(struct file *, unsigned int, unsigned long);
   int (*mmap)(struct file *, struct vm_area_struct *);
   int (*open)(struct inode *, struct file *);
   int (*flush)(struct file *, fl_owner_t id);
   int (*release)(struct inode *, struct file *);
   int (*fsync)(struct file *, loff_t, loff_t, int datasync);
   int (*fasync)(int, struct file *, int);
   int (*lock)(struct file *, int, struct file_lock *);
   unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
   int (*check_flags)(int);
   int (*flock)(struct file *, int, struct file_lock *);
   ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, loff_t *, size_t, unsigned int);
   ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *, size_t, unsigned int);
   void (*splice_eof)(struct file *file);
   int (*setlease)(struct file *, int, struct file_lease **, void **);
   long (*fallocate)(struct file *file, int mode, loff_t offset,
                     loff_t len);
   void (*show_fdinfo)(struct seq_file *m, struct file *f);
#ifndef CONFIG_MMU
   unsigned (*mmap_capabilities)(struct file *);
#endif
   ssize_t (*copy_file_range)(struct file *, loff_t, struct file *,
                              loff_t, size_t, unsigned int);
   loff_t (*remap_file_range)(struct file *file_in, loff_t pos_in,
                              struct file *file_out, loff_t pos_out,
                              loff_t len, unsigned int remap_flags);
   int (*fadvise)(struct file *, loff_t, loff_t, int);
   int (*uring_cmd)(struct io_uring_cmd *ioucmd, unsigned int issue_flags);
   int (*uring_cmd_iopoll)(struct io_uring_cmd *, struct io_comp_batch *,
                           unsigned int poll_flags);
} __randomize_layout;

struct file_operations
{
   struct module *owner;
   fop_flags_t fop_flags;
   loff_t (*llseek)(struct file *, loff_t, int);
   ssize_t (*read)(struct file *, char __user *, size_t, loff_t *);
   ssize_t (*write)(struct file *, const char __user *, size_t, loff_t *);
   ssize_t (*read_iter)(struct kiocb *, struct iov_iter *);
   ssize_t (*write_iter)(struct kiocb *, struct iov_iter *);
   int (*iopoll)(struct kiocb *kiocb, struct io_comp_batch *,
                 unsigned int flags);
   int (*iterate_shared)(struct file *, struct dir_context *);
   __poll_t (*poll)(struct file *, struct poll_table_struct *);
   long (*unlocked_ioctl)(struct file *, unsigned int, unsigned long);
   long (*compat_ioctl)(struct file *, unsigned int, unsigned long);
   int (*mmap)(struct file *, struct vm_area_struct *);
   int (*open)(struct inode *, struct file *);
   int (*flush)(struct file *, fl_owner_t id);
   int (*release)(struct inode *, struct file *);
   int (*fsync)(struct file *, loff_t, loff_t, int datasync);
   int (*fasync)(int, struct file *, int);
   int (*lock)(struct file *, int, struct file_lock *);
   unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
   int (*check_flags)(int);
   int (*flock)(struct file *, int, struct file_lock *);
   ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, loff_t *, size_t, unsigned int);
   ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *, size_t, unsigned int);
   void (*splice_eof)(struct file *file);
   int (*setlease)(struct file *, int, struct file_lease **, void **);
   long (*fallocate)(struct file *file, int mode, loff_t offset,
                     loff_t len);
   void (*show_fdinfo)(struct seq_file *m, struct file *f);
#ifndef CONFIG_MMU
   unsigned (*mmap_capabilities)(struct file *);
#endif
   ssize_t (*copy_file_range)(struct file *, loff_t, struct file *,
                              loff_t, size_t, unsigned int);
   loff_t (*remap_file_range)(struct file *file_in, loff_t pos_in,
                              struct file *file_out, loff_t pos_out,
                              loff_t len, unsigned int remap_flags);
   int (*fadvise)(struct file *, loff_t, loff_t, int);
   int (*uring_cmd)(struct io_uring_cmd *ioucmd, unsigned int issue_flags);
   int (*uring_cmd_iopoll)(struct io_uring_cmd *, struct io_comp_batch *,
                           unsigned int poll_flags);
} __randomize_layout;

If this structure contains functions that aren’t required for your driver, you can still use the device file without implementing them. A pointer to an unimplemented function can simply be set to NULL. After that, the system will take care of implementing the function and make it behave normally. In our case, we’ll just implement the read function.

As we’re going to ensure the operation of only a single type of device with our Linux driver, our file_operations structure will be global and static. After it’s created, you’ll need to fill it statically like this:

static const struct file_operations simple_driver_fops =
{
   .owner = THIS_MODULE,
   .read = device_file_read,
};

static const struct file_operations simple_driver_fops =
{
   .owner = THIS_MODULE,
   .read = device_file_read,
};

The declaration of the THIS_MODULE macro is contained in the linux/init.h header file. We’ll transform the macro into a pointer to the module structure of the required module. Later, we’ll write the body of the function with a prototype. But for now, we have only the device_file_read pointer to it:

static ssize_t device_file_read(
   struct file *file_ptr, char __user *user_buffer, size_t count, loff_t *position)

static ssize_t device_file_read(
   struct file *file_ptr, char __user *user_buffer, size_t count, loff_t *position)

3. Create a device class and register a character device file

The last step of developing our character device involves creating a device class and registering a device file. A device class is a high-level view of the logical device group in the Linux Device Model, which abstracts implementation details. You need a device class to create a device, which is a specific instance of the device with an allocated device number. Based on this device instance, the system creates a device file in the /dev directory.

Note: This step is optional, so you can stop after the Add a character device to the system step and proceed with the mknod user space command to create a device file in the /dev folder. However, it’s usually much more helpful to use the kernel module to create a character device file. 

Let’s examine what functions are required to complete the creation of a character device in the kernel module. 

The function to create a device class requires only the name for the new device class:

struct class *class_create(const char *name);

struct class *class_create(const char *name);

The device_create function is more complicated:

struct device *device_create(
   const struct class *class, struct device *parent,
   dev_t devt, void *drvdata, const char *fmt, ...)

struct device *device_create(
   const struct class *class, struct device *parent,
   dev_t devt, void *drvdata, const char *fmt, ...)

You need to pass the following arguments to the device_create function:

• Pointer to the created class
• Pointer (for the new device) to the parent device; NULL may be used if there is no parent device
• Device number received from the alloc_chrdev_region function
• Pointer to the data to be passed to the device callbacks; as we don’t use the pointer, we’ll use NULL for this parameter
• String for the device name; may be parametrized, but in our case, we’ll use a regular string

Here’s what calling this function looks like in the kernel module:

  g_device = device_create(g_class, NULL, g_devno, NULL, device_name);
   if (IS_ERR(g_device))
   {
       result = PTR_ERR(g_device);
       pr_err("Simple-driver: device_create failed: %d\n", result);
       goto err_class_destroy;
   }

  g_device = device_create(g_class, NULL, g_devno, NULL, device_name);
   if (IS_ERR(g_device))
   {
       result = PTR_ERR(g_device);
       pr_err("Simple-driver: device_create failed: %d\n", result);
       goto err_class_destroy;
   }

Logging macros

In the code above, we’ve added the pr_err macro that logs kernel messages. You can find other macros of this type, such as pr_info and pr_warn, in linux/printk.h. Pay attention to the macro’s name. It must contain a log level.

The levels range from insignificant (pr_devel) to critical (pr_emerg), alerting about kernel instability. The pr_* macros form a string, which we add to the circular buffer. From there, the klog daemon reads it and sends it to the system log. Implementation of the pr_err macros allows for calling them from almost any point in the kernel. 

Use these macros carefully, as they might cause overflow of the circular buffer, in which case the oldest message will not be logged.

Read also

Linux Driver Development with Rust: Benefits, Challenges, and a Practical Example

Get practical insights on how to enhance the security of your Linux driver by building Rust-based solutions.

Learn more

Implementation of the character device’s registering function

Once you use all the functions described above (i.e., functions implemented in the kernel), you’ll get your own function for registering a character device:

int register_device(void)
{
   int result = 0;
   pr_notice("Simple-driver: register_device() is called.\n");
   unsigned baseminor = 0;
   unsigned minor_count_required = 1;

   result = alloc_chrdev_region(&g_devno, baseminor, minor_count_required, device_name);
   if (result)
   {
       pr_err("Simple-driver: alloc_chrdev_region failed: %d\n", result);
       goto err_out;
   }

   cdev_init(&g_cdev, &simple_driver_fops);
   g_cdev.owner = THIS_MODULE;
   result = cdev_add(&g_cdev, g_devno, minor_count_required);
   if (result)
   {
       pr_err("Simple-driver: cdev_add failed: %d\n", result);
       goto err_unregister_chrdev_region;
   }

   g_class = class_create(class_name);
   if (IS_ERR(g_class))
   {
       result = PTR_ERR(g_class);
       pr_err("Simple-driver: class_create failed: %d\n", result);
       goto err_cdev_del;
   }

   g_device = device_create(g_class, NULL, g_devno, NULL, device_name);
   if (IS_ERR(g_device))
   {
       result = PTR_ERR(g_device);
       pr_err("Simple-driver: device_create failed: %d\n", result);
       goto err_class_destroy;
   }

   pr_notice("Simple-driver: Registered character device with major number = %i, minor number = %i\n", MAJOR(g_devno), MINOR(g_devno));
   return 0;

err_class_destroy:
   if (!IS_ERR_OR_NULL(g_class))
   {
       class_destroy(g_class);
       g_class = NULL;
   }

err_cdev_del:
   cdev_del(&g_cdev);

err_unregister_chrdev_region:
   if (g_devno)
   {
       unsigned minor_count_allocated = 1;
       unregister_chrdev_region(g_devno, minor_count_allocated);
       g_devno = 0;
   }

err_out:
   return result;
}

int register_device(void)
{
   int result = 0;
   pr_notice("Simple-driver: register_device() is called.\n");
   unsigned baseminor = 0;
   unsigned minor_count_required = 1;

   result = alloc_chrdev_region(&g_devno, baseminor, minor_count_required, device_name);
   if (result)
   {
       pr_err("Simple-driver: alloc_chrdev_region failed: %d\n", result);
       goto err_out;
   }

   cdev_init(&g_cdev, &simple_driver_fops);
   g_cdev.owner = THIS_MODULE;
   result = cdev_add(&g_cdev, g_devno, minor_count_required);
   if (result)
   {
       pr_err("Simple-driver: cdev_add failed: %d\n", result);
       goto err_unregister_chrdev_region;
   }

   g_class = class_create(class_name);
   if (IS_ERR(g_class))
   {
       result = PTR_ERR(g_class);
       pr_err("Simple-driver: class_create failed: %d\n", result);
       goto err_cdev_del;
   }

   g_device = device_create(g_class, NULL, g_devno, NULL, device_name);
   if (IS_ERR(g_device))
   {
       result = PTR_ERR(g_device);
       pr_err("Simple-driver: device_create failed: %d\n", result);
       goto err_class_destroy;
   }

   pr_notice("Simple-driver: Registered character device with major number = %i, minor number = %i\n", MAJOR(g_devno), MINOR(g_devno));
   return 0;

err_class_destroy:
   if (!IS_ERR_OR_NULL(g_class))
   {
       class_destroy(g_class);
       g_class = NULL;
   }

err_cdev_del:
   cdev_del(&g_cdev);

err_unregister_chrdev_region:
   if (g_devno)
   {
       unsigned minor_count_allocated = 1;
       unregister_chrdev_region(g_devno, minor_count_allocated);
       g_devno = 0;
   }

err_out:
   return result;
}

Unregistering a device

Having explored all the functions required to create and register a character device, you can implement safe device unregistering. This operation must be performed during kernel module unloading for cleanup.

To unregister a device, use the following code:

void unregister_device(void)
{
   pr_notice("Simple-driver: unregister_device() is called\n");
   if (!IS_ERR_OR_NULL(g_device))
   {
       device_destroy(g_class, g_devno);
       g_device = NULL;
   }


   if (!IS_ERR_OR_NULL(g_class))
   {
       class_destroy(g_class);
       g_class = NULL;
   }


   cdev_del(&g_cdev);


   if (g_devno)
   {
       unsigned minor_count_allocated = 1;
       unregister_chrdev_region(g_devno, minor_count_allocated);
       g_devno = 0;
   }
   pr_info("Simple-driver: Unregistered\n");
}

void unregister_device(void)
{
   pr_notice("Simple-driver: unregister_device() is called\n");
   if (!IS_ERR_OR_NULL(g_device))
   {
       device_destroy(g_class, g_devno);
       g_device = NULL;
   }


   if (!IS_ERR_OR_NULL(g_class))
   {
       class_destroy(g_class);
       g_class = NULL;
   }


   cdev_del(&g_cdev);


   if (g_devno)
   {
       unsigned minor_count_allocated = 1;
       unregister_chrdev_region(g_devno, minor_count_allocated);
       g_devno = 0;
   }
   pr_info("Simple-driver: Unregistered\n");
}

The next stage of implementing functions for our kernel module is to work with memory allocated in user mode. Let’s see how to do it.

Using memory allocated in user mode

The read function we’re going to create will handle read operations performed on a character device file from the user space. The signature of this function must be appropriate for the function from the file_operations structure:

ssize_t (*read)(struct file *filep, char __user * buffer, size_t len, loff_t * offset);

ssize_t (*read)(struct file *filep, char __user * buffer, size_t len, loff_t * offset);

Where:

• The filep parameter is the pointer to the file structure. This file structure allows us to get the necessary information about the file we’re working with, data related to this file, and more.
• The buffer is a pointer to the memory allocated in the user space where we store the requested data.
• The number of bytes to be read is defined in the len parameter, and we start reading bytes from a certain offset defined in the offset parameter. After executing the function, the number of bytes that have been successfully read must be returned.

read function characteristics

To work with information from the device file, the user allocates a special buffer in the user-mode address space. Then, the read function copies the information to this buffer. The address to which a pointer from the user space points and the address in the kernel address space may have different values. That’s why you cannot simply dereference the pointer.

When working with these pointers, we have a set of specific macros and functions we declare in the linux/uaccess.h file. The most suitable function in our case is copy_to_user. Its name speaks for itself: this function copies specific data from the kernel buffer to the buffer allocated in the user space. It also verifies if a pointer is valid and if the buffer size is large enough. Here’s the copy_to_user function interface:

copy_to_user(void __user *to, const void *from, unsigned long n)

copy_to_user(void __user *to, const void *from, unsigned long n)

First of all, this function must receive three parameters:

• A pointer to the userspace-allocated buffer
• A pointer to the data source allocated in the kernel space
• The number of bytes to be copied

If there are any errors in execution, the function will return a value other than 0. In case of successful execution, the value will be 0. The copy_to_user function contains the __user macro that documents the process. This function also allows us to find out if the code uses pointers from the address space correctly. This is done using Sparse, an analyzer for static code. To be sure that it works correctly, always mark the user address space pointers as __user.

Here’s the code for implementing the read function:

static ssize_t device_file_read(
   struct file *file_ptr, char __user *user_buffer, size_t count, loff_t *position)
{
   pr_notice("Simple-driver: Read from device file offset = %i, read bytes count = %u\n", (int)*position, (unsigned int)count);


   if (*position >= g_s_Hello_World_size)
       return 0;


   if (*position + count > g_s_Hello_World_size)
       count = g_s_Hello_World_size - *position;


   if (copy_to_user(user_buffer, g_s_Hello_World_string + *position, count) != 0)
       return -EFAULT;


   *position += count;
   return count;
}

static ssize_t device_file_read(
   struct file *file_ptr, char __user *user_buffer, size_t count, loff_t *position)
{
   pr_notice("Simple-driver: Read from device file offset = %i, read bytes count = %u\n", (int)*position, (unsigned int)count);


   if (*position >= g_s_Hello_World_size)
       return 0;


   if (*position + count > g_s_Hello_World_size)
       count = g_s_Hello_World_size - *position;


   if (copy_to_user(user_buffer, g_s_Hello_World_string + *position, count) != 0)
       return -EFAULT;


   *position += count;
   return count;
}

With this function, the code for our driver is ready. Now, it’s time to build the kernel module and see if it works as expected.

Building the kernel module

In modern kernel versions, the Makefile does most of the building for a developer. It starts the kernel build system and provides the kernel with information about the components required to build the module.

A module built from a single source file requires a single string in the Makefile. After creating this file, you only need to initiate the kernel build system with the obj-m := source_file_name.o command. As you can see, in our example, we’ve assigned the source file name to the module (the *.ko file).

If there are several source files, only two strings are required for the kernel build:

obj-m := module_name.o
module_name-objs := source_1.o source_2.o … source_n.o

obj-m := module_name.o
module_name-objs := source_1.o source_2.o … source_n.o

To initialize the kernel build system and build the module, use the make –C KERNEL_MODULE_BUILD_SYSTEM_FOLDER M=`pwd` modules command. 

To clean up the build folder, you can use the make –C KERNEL_MODULES_BUILD_SYSTEM_FOLDER M=`pwd` clean command.

The module build system is commonly located in /lib/modules/`uname -r`/build. Now, it’s time to prepare the module build system. To build our first module, we’ll execute the make modules_prepare command from the folder where the build system is located. 

Finally, we’ll combine everything we’ve learned into one Makefile:

TARGET_MODULE:=simple-module


# If we are running with kernel building system
ifneq ($(KERNELRELEASE),)
   $(TARGET_MODULE)-objs := main.o device_file.o
   obj-m := $(TARGET_MODULE).o


# If we are running without kernel build system
else
   BUILDSYSTEM_DIR:=/lib/modules/$(shell uname -r)/build
   PWD:=$(shell pwd)




all :
# run kernel build system to make module
   $(MAKE) -C $(BUILDSYSTEM_DIR) M=$(PWD) modules


clean:
# run kernel build system to clean up in current directory
   $(MAKE) -C $(BUILDSYSTEM_DIR) M=$(PWD) clean


load:
   insmod ./$(TARGET_MODULE).ko


unload:
   rmmod ./$(TARGET_MODULE).ko


endif

TARGET_MODULE:=simple-module


# If we are running with kernel building system
ifneq ($(KERNELRELEASE),)
   $(TARGET_MODULE)-objs := main.o device_file.o
   obj-m := $(TARGET_MODULE).o


# If we are running without kernel build system
else
   BUILDSYSTEM_DIR:=/lib/modules/$(shell uname -r)/build
   PWD:=$(shell pwd)




all :
# run kernel build system to make module
   $(MAKE) -C $(BUILDSYSTEM_DIR) M=$(PWD) modules


clean:
# run kernel build system to clean up in current directory
   $(MAKE) -C $(BUILDSYSTEM_DIR) M=$(PWD) clean


load:
   insmod ./$(TARGET_MODULE).ko


unload:
   rmmod ./$(TARGET_MODULE).ko


endif

The load target loads the build module, and the unload target deletes it from the kernel.

In our tutorial for device driver development in Linux, we’ve used code from main.c and device_file.c to compile a driver. The resulting driver is named simple-module.ko. Let’s see how to use it.

Related project

Custom Cybersecurity Solution Development: From MVP to Support and Maintenance

Find out how Apriorit experts helped our client build an MVP of a cybersecurity product and then extend its functionality, including by developing and implementing drivers.

Project details

Loading the kernel module

To load the module, you have to execute the make load command from the source file folder. After this, the name of the driver is added to the /proc/modules file, while the device that the module registers is added to /proc/devices. The added records look like this:

$> cat /proc/devices 
Character devices:
  1 mem
  4 /dev/vc/0
  4 tty
  4 ttyS
  5 /dev/tty
…..
506 simple-driver
…..

$> cat /proc/devices 
Character devices:
  1 mem
  4 /dev/vc/0
  4 tty
  4 ttyS
  5 /dev/tty
…..
506 simple-driver
…..

In the /dev folder, you can find the created character device file: /dev/simple-driver.

To perform the final verification and be sure that everything works as expected, you can use the cat command to display the device file contents:

$> cat /dev/simple-driver
Hello world from kernel mode!

$> cat /dev/simple-driver
Hello world from kernel mode!

If you see the contents of your driver, it’s working correctly. As a result of all the work above, you’ll get a basic device driver that you can use as a starting point to build a full-fledged Linux driver solution. You can find the source code for further driver development in the Apriorit GitHub repository.

How Apriorit can help with Linux driver development

Developing secure and reliable Linux device drivers requires deep expertise in the field. At Apriorit, we have been dealing with kernel and driver development for more than 20 years, providing our clients with unique development expertise in Linux, Windows, and macOS.

If you’re looking for a reliable vendor to entrust with Linux driver development, Apriorit can assist you with the following:

• Custom device driver development. Whatever tasks and requirements you have in mind, we’ll help you build customized Linux driver solutions that meet your goals.
• Legacy driver modernization. Delegate the research of your solution to Apriorit experts and prolong the life of your project. We’ll find the best way to introduce essential improvements, ensure proper security, and enhance performance according to your request.
• Driver security improvements. Enhance your driver security posture by outsourcing cybersecurity tasks to Apriorit specialists. We’ll help you boost your driver protection by performing a security code audit, driver security testing, and static code analysis.
• Driver solution support and maintenance. If you need robust full-scale post-release maintenance for your driver solution, entrust it to Apriorit professionals. We’ll provide you with various maintenance and support activities, including developing new features for drivers on demand, providing security updates, and supporting legacy system compatibility.

Conclusion

Building stable device drivers is important for ensuring smooth interaction between the Linux operating system and hardware. In this article, we show a practical example of how you can create a simple Linux device driver that can be used as the starting point for developing complex driver solutions.

At Apriorit, we’ve made Linux kernel and driver development our speciality. Our developers have successfully delivered hundreds of complex drivers for Linux and Unix systems. By outsourcing challenging driver development tasks to Apriorit professionals, you’ll get a robust solution that meets your needs and expectations.

FAQ