mjhjmtu

I am trying to understand character special files. From wikipedia, I understand that these files
"provide an interface" for devices that transmit data one character at a time. My understanding is that the system somehow calls the character device instead of calling the device driver directly. But how does the file provide this interface? Is it an executable that translates the system call? Can someone explain what's up.

They are actually just that - interfaces. Encoded by a "major" and "minor" number they provide a hook to the kernel.

They come in two flavors (well, three, but named pipes are out of the scope of this explanation for now): Character Devices and Block Devices.

Block Devices tend to be storage devices, capable of buffering output and storing data for later retrieval.

Character Devices are things like audio or graphics cards, or input devices like keyboard and mouse.

In each case, when the kernel loads the correct driver (either at boot time, or via programs like udev) it scans the various buses to see if any devices handled by that driver are actually present on the system. If so, it sets up a device that 'listens' on the appropriate major/minor number.

(For instance, the Digital Signal Processor of the first audio card found by your system gets the major/minor number pair of 14/3; the second gets 14,35, etc.)

It's up to udev to create an entry in /dev named dsp as a character device marked major 14 minor 3.

(In significantly older or minimum-footprint versions of Linux, /dev/ may not be dynamically loaded but just contain all possible device files statically.)

Then, when a userspace program tries to access a file that's marked as a 'character special file' with the appropriate major/minor number (for instance, your audio player trying to send digital audio to /dev/dsp ), the kernel knows that this data needs to be transmitted via the driver that major/minor number is attached to; presumably said driver knows what to do with it in turn.

Every file, device or otherwise, supports 6 basic operations within the VFS:

1. Open


2. Close


3. Read


4. Write


5. Seek


6. Tell

Additionally, device files support I/O Control, which allows other miscellaneous operations not covered by the first 6.

In the case of a character special, seek and tell are not implemented since they support a streaming interface. That is, reading or writing directly such as is done with redirection in the shell:

echo 'foo' > /dev/some/char
sed ... < /dev/some/char

Minimal runnable file_operations example

Once you see a minimal example, it all becomes obvious.

The key ideas are:

• 
  file_operations contains the callbacks for each file related syscall


• 
  mknod path c major minor creates a character device which uses those file_operations
  


• for character devices that dynamically allocate device numbers (the norm to avoid conflicts), find the number with cat /proc/devices

character_device.ko kernel module:

#include <asm/uaccess.h> /* copy_from_user, copy_to_user */
#include <linux/errno.h> /* EFAULT */
#include <linux/fs.h> /* register_chrdev, unregister_chrdev */
#include <linux/jiffies.h>
#include <linux/module.h>
#include <linux/printk.h> /* printk */
#include <uapi/linux/stat.h> /* S_IRUSR */

#define NAME "lkmc_character_device"

MODULE_LICENSE("GPL");

static int major;

static ssize_t read(struct file *filp, char __user *buf, size_t len, loff_t *off)

 size_t ret;
 char kbuf = 'a', 'b', 'c', 'd';

 ret = 0;
 if (*off == 0) 
 if (copy_to_user(buf, kbuf, sizeof(kbuf))) 
 ret = -EFAULT;
 else 
 ret = sizeof(kbuf);
 *off = 1;
 
 
 return ret;


static const struct file_operations fops = 
 .owner = THIS_MODULE,
 .read = read,
;

static int myinit(void)

 major = register_chrdev(0, NAME, &fops);
 return 0;


static void myexit(void)

 unregister_chrdev(major, NAME);


module_init(myinit)
module_exit(myexit)

Userland test program:

insmod /character_device.ko
dev="lkmc_character_device"
major="$(grep "$dev" /proc/devices | cut -d ' ' -f 1)"
mknod "/dev/$dev" c "$major" 0
cat /dev/lkmc_character_device
# => abcd
rm /dev/lkmc_character_device
rmmod character_device

GitHub QEMU + Buildroot upstream with boilerplate to actually run it:

• https://github.com/cirosantilli/linux-kernel-module-cheat/blob/6788a577c394a2fc512d8f3df0806d84dc09f355/kernel_module/character_device.c


• https://github.com/cirosantilli/linux-kernel-module-cheat/blob/master/rootfs_overlay/character_device.sh

More complex examples:

• 
  read, write, lseek with a fixed size internal buffer and on debugfs instead of a character device: https://github.com/cirosantilli/linux-kernel-module-cheat/blob/6788a577c394a2fc512d8f3df0806d84dc09f355/kernel_module/fops.c
  


• 
  poll: https://github.com/cirosantilli/linux-kernel-module-cheat/blob/6788a577c394a2fc512d8f3df0806d84dc09f355/kernel_module/poll.c
  


• 
  ioctl: https://github.com/cirosantilli/linux-kernel-module-cheat/blob/6788a577c394a2fc512d8f3df0806d84dc09f355/kernel_module/poll.c
  


• 
  anon_inode_getfd associates a file_operations to a file descriptor without any filesystem file: https://stackoverflow.com/questions/4508998/what-is-anonymous-inode/44388030#44388030
  

"Character at a time" is a misnomer (as is the idea that character devices necessarily do not support seek and tell). In fact, "block at a time" (i.e. strictly record-oriented, such as a tape drive*) devices must be character devices. So is the idea that a character device must necessarily be unseekable - character device drivers define a full file_operations structure which is free to define llseek or not according to whether the device supports the operation. The character devices most people think of as examples are null, urandom, TTY devices, sound card, mouse, etc... which are all unseekable because of the specifics of what those devices are, but /dev/vcs, /dev/fb0, and /dev/kmem are also character devices and they are all seekable.

As I mentioned, a character device driver defines a file_operations structure that has function pointers for all the operations someone might want to call on a file - seek, read, write, ioctl, etc - and these are each called once when the corresponding system call is executed with this device file open. And read and write can therefore do whatever it wants with its arguments - it can refuse to accept a write that's too large or only write what fits; it can read only the data corresponding to one record rather than the whole requested number of bytes.

So, what is a block device, then? Basically, block devices are disk drives. No other kind of device (except for virtual disk drives, like ramdisk and loopback) is a block device. They are integrated into the I/O request system, the filesystem layer, the buffer/cache system, and the virtual memory system in a way that character devices are not, even when you're accessing e.g. /dev/sda from a user process. Even the "raw devices" that page mentions as an exception are character devices.

*Some UNIX systems implemented what is now called "fixed-block mode" - which lets the kernel group and split I/O requests to fit the configured block boundaries in more or less the same manner as is done for disk drives - as a block device. A character device is needed for "variable-block mode", which preserves block boundaries from the user program as a single write(2) call writes one block and a single read(2) call returns one block. Since mode switching is implemented now as an ioctl rather than a separate device file, a character device is used. Variable-record tape drives are mostly "non-seekable" because seeking involves counting a number of records rather than a number of bytes, and the native seek operation is implemented as an ioctl.

Character devices can be created by kernel modules (or the kernel itself). When a device is created, the creator provides pointers to functions that implement handle standard calls like open, read, etc. The Linux kernel then associates those functions with the character device, so for example when a user-mode application calls the read() function on a character device file, it will result in a syscall and then the kernel will route this call to a read function specified when creating the driver.
There's a step-by-step tutorial on creating a character device here, you can create a sample project and the step through it using a debugger to understand how the device object is created and when the handlers are invoked.