Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

How are character special files and block special files different from regular files in a Inix-like system? Why are they called “character special” and “block special” respectively?

share|improve this question

2 Answers 2

up vote 8 down vote accepted

When a program reads or writes data from a file, the requests go to a kernel driver. If the file is a regular file, the data is handled by a filesystem driver and it is typically stored in zones on a disk or other storage media, and the data that is read from a file is what was previously written in that place. There are other file types for which different things happen.

When data is read or written to a device file, the request is handled by the driver for that device. Each device file has an associated number which identifies the driver to use. What the device does with the data is its own business.

Block devices (also called block special files) usually behave a lot like ordinary files: they are an array of bytes, and the value that is read at a given location is the value that was last written there. Data from block device can be cached in memory and read back from cache; writes can be buffered. Block devices are normally seekable (i.e. there is a notion of position inside the file which the application can change). The name “block device” comes from the fact that the corresponding hardware typically reads and writes a whole block at a time (e.g. a sector on a hard disk).

Character devices (also called character special files) behave like pipes, serial ports, etc. Writing or reading to them is an immediate action. What the driver does with the data is its own business. Writing a byte to a character device might cause it to be displayed on screen, output on a serial port, converted into a sound, ... Reading a byte from a device might cause the serial port to wait for input, might return a random byte (/dev/urandom), ... The name “character device” comes from the fact that each character is handled individually.

See Wikipedia and Understanding /dev and its subdirs and files for more information.

share|improve this answer
    
@Giles what is the role of the kernel driver for regular files ? I mean how does the kernel driver talk to the filesystem driver ? –  Geek Jan 3 '13 at 6:29
    
@Geek Which kernel driver? I don't understand the question. –  Gilles Jan 3 '13 at 10:11
    
@Giles The kernel driver that you talked about in the first line of your answer. –  Geek Jan 3 '13 at 15:22
    
@Geek In the case of a regular file, the filesystem driver is the kernel driver in question. –  Gilles Jan 3 '13 at 15:50
    
@Giles and no kernel driver is involved for devices ? –  Geek Jan 3 '13 at 16:15

They point to a driver and can be created by [mknod][1]. Looking at its man page, it seems that block devices are buffered while character devices are unbuffered. Block devices have a "block size" that indicate the size of the blocks that are accessible. (for storage devices, the block size is typically between 512 B and 4 KiB) Storage devices and memory are typically accessed as block devices, while devices such as serial ports and terminals are typically accessed as character devices.

They are typically found in /dev (and can not function on partitions mounted with a nodev option (or its equivalent))

In ls -l show two comma-separated numbers for devices in the place where the size is normally found. Those are the major and minor numbers, that point to the driver. Their type are also indicated as "c" or "b" in the permission column of the ls -l output.

/dev can be populated in several ways. On recent Linux kernel versions udev is typically used, on Solaris it contains links to /devices, which is a virual devfs filesystem.

share|improve this answer
    
You might want to add that block devices, as the name suggests, are interfaces for devices that have a minimum block size they can read/write bigger than 1 byte - typical example is a hard drive with 512B/4KB sectors. As for the creation, in the olden days the special files in /dev were created by the init scripts (and the system wouldn't boot without some important ones - like /dev/null - being present). –  peterph Jan 2 '13 at 8:59
    
I assume they might still be manually created for some embedded systems or highly limited chroot environments... What I haven't figured out, is to determine what the major number should be if you manually create it.. (The major number seem to refer to the driver (at least on SCO which is what I found documentation for) and the minor number is a parameter for it...) Not sure if the major number is hardcoded in the driver... (And I assume it might differ between different variants..) –  Gert van den Berg Jan 2 '13 at 11:49
    
About block devices: Would they always have a block size? Just noticed that on Solaris, the disk can be accessed either as a block device (linked in /dev/dsk) or as a character device (the ",raw" (/dev/rdsk) variant) Interestingly, they have the same major and minor numbers. (On the Linux system that I checked, only the disks and ram devices are block devices) –  Gert van den Berg Jan 2 '13 at 11:58
    
see e.g. Linux device drivers for discussion on how to find/allocate the numbers in Linux kernel. As for the block size: I suppose there has to be a sector size in the software layer, otherwise it would just be a character device. Whether you can access disk as char device is just a convenient shortcut running on top of block device I would say (because that's how the hardware works in the end). –  peterph Jan 2 '13 at 12:20
    
So short version: Minor / Major number assignments are OS dependent and on Linux, driver dependent as well. (Some hard-coded, some dynamic) –  Gert van den Berg Jan 2 '13 at 15:19

Your Answer

 
discard

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.