Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
up vote 8 down vote accepted

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

share|improve this answer
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) 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
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
share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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