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.

  • 1
    1. So major/minor numbers are analogous to ports? – bernie2436 May 3 '12 at 15:38
  • 2. So when programs access any file, the kernel reads these special interfaces to learn if the program should get interrupts from a particular device? Ex: if a program opens a word file, it reads the character device special file to know the program should respond to keyboard input? – bernie2436 May 3 '12 at 15:45
  • 1) Somewhat. It's a poor man's analogy but it'll do. – Shadur May 3 '12 at 17:21
  • 2
    2) You're missing about three or four layers of abstraction there. The program you open a text file with neither knows nor cares what the keyboard device is. Communication with the underlying hardware happens either via the terminal emulator (if you're in console mode) or via the X event layer (if you're in graphics mode), either of which will listen to the keyboard and other drives and decides what, if anything, to pass on to the program. I'm summarizing a fairly complex multilayer system here; you might do well to read up on the X Window System in general. – Shadur May 3 '12 at 17:24
  • 1
    Note also that, on some flavors of UN*X, there are character special files for storage devices; a read or a write to the special file turns into a read or write to a sequence of blocks on the device. (In recent versions of FreeBSD, those are the only special files for storage devices; there are no block special files.) – user44841 Oct 22 '14 at 0:34

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
  • Process substitution files don't support seeking. – Sapphire_Brick Feb 16 at 23:12

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"


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


Userland test program:

insmod /character_device.ko
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:

More complex examples:

  • This was super helpful thanks! Just one question, what exactly does this do *off = 1;, and why is it set to 1? – SilverSlash Nov 3 '18 at 12:28
  • 1
    @SilverSlash that value gets passed across multiple read calls to the same open( file descriptor. The driver can do whatever it wants with it. The usual semantic, is to contain the number of bytes read. In this example however, we just have a simpler semantic: 0 for the first read, 1 after the first read. Try to run it and put a printk or GDB step debug it. – Ciro Santilli新疆棉花TRUMP BAN BAD Nov 3 '18 at 16:19

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.