In designing any operating system, one question that has to be answered is, “How do programs talk to physical devices?” The UNIX answer is for the system to provide device files. When a program accesses them, they act almost exactly like ordinary files, but the kernel passes the accesses to those special files to device drivers. These files are traditionally found in the /dev directory.
To understand device files, you should start by looking at the contents of the /dev directory:
ls -l /dev
You'll see that these special files have a few differences from normal files. First, the first character of the permissions is either “b” or “c”, indicating that the device is either a block or character device. Second, instead of a file size, there are two numbers. These are the major and minor device numbers. When you access one of these files, the operating system looks up the major device number in either the block or character driver table to find the device driver (possibly with the help of kerneld, in the case of modules). The minor number is used by the device driver for such things as multiple instances of the same device or different aspects of the device.
You may also note a few files whose first permission character is “s”, indicating that they are sockets. Unlike devices, which are handled by the kernel, these are created by daemons when the system boots. For example, /dev/printer is a socket controlled by the lpd daemon. If you kill the lpd process, /dev/printer will vanish.
If you have the Linux kernel source installed, you can find out what a device is used for by looking up its device type and number in the file /usr/src/linux/Documentation/devices.txt. With most Linux distributions, you'll find that device files exist for a number of strange operations that you wouldn't expect to use. However, you should be very careful about deleting any devices; removing the wrong files can result in making it impossible to use your system until you restore the file, after rebooting from a floppy. So make sure you have a boot floppy to rescue your system in case you make a mistake. Of course, you can't do much to mess up the /dev directory unless you are running as root.
There are two ways to create device files. The recommended way is to use a program called MAKEDEV. You can also create them manually using the mknod program. We will consider them here in reverse order.
To use mknod, you need to know the name of the device, the type (character or block), and the major and minor device numbers. As an example, I once erased /dev/zero. After rebooting from a floppy and mounting my normal file system on /mnt, I wanted to create /mnt/dev/zero. I knew that /dev/zero is supposed to be a character device, with the major number 1 and the minor number 5. The command I used to create the device was:
mknod /mnt/dev/zero c 5 1
I then had to use chmod, chown and chgrp to set the access permissions and ownership, just as with a regular file. You'll probably want to read the man page for mknod before using it.
If that sounded like a pain, you're right. Fortunately, there's a better way. Instead of calling mknod directly, you can use a script called MAKEDEV that already knows the device types, numbers, permissions and ownership for all the standard devices. MAKEDEV uses mknod to create the devices but saves you the work of figuring out the details. For example, typing MAKEDEV generic will create most, if not all, of the devices you would want for a typical system. It is a good idea to read the man page for MAKEDEV before using it.
/dev/null is the proverbial bit bucket. Shell scripts often redirect the output of commands to /dev/null to avoid cluttering the display with unwanted output. When used for input, it acts as an empty file.
/dev/random and /dev/urandom access the kernel's random number generator. The kernel keeps track of various “random” events, such as disk and keyboard activity, and uses a cryptographic hash to generate highly random numbers. It also keeps track of an estimate of how much random information it has. If you use /dev/random, it will only give you as much information as it has available. If you use /dev/urandom, it will give you an unlimited amount of random information, but without as strong a guarantee on its unpredictability. Although the kernel uses this feature internally, very few programs access it through the device files.
/dev/zero generates an infinite stream of zeros. It is used every time you start up an ELF process that uses shared libraries, making it one of the most important files in /dev.
IDE hard drives and CD-ROM drives are accessed through /dev/hd*. Most newer PC motherboards include two IDE interfaces, each capable of controlling a master and a slave. hda and hdb are the master and slave drives on the first interface, and hdc and hdd are the master and slave on the second interface. The number at the end of the device name refers to the partition number, with 1 through 4 being the primary partitions and 5 and up being extended partitions.
Those familiar with other versions of UNIX will be surprised to find that all the IDE devices are block devices. Traditionally, there would also be character devices for the drives, and you would have to be careful which one you used for a given program. (For example, fsck wants to use the character device, but you mount the block device—not a good idea.) Linux allows programs to access a block device as if it were a character device, so there is no need for character devices for hard drives.
SCSI devices are a bit more complicated than IDE. If you have a SCSI card with multiple devices, you probably already know that each device has a SCSI ID number between 0 and 7. When the SCSI card is initialized, the operating system asks it which devices are attached. These devices are separated into several categories. The first hard drive found (the one with the lowest ID number) is sda, the first CD-ROM drive is sr0, the first tape drive is sta, and the first generic device (usually a scanner) is sga. So when accessing SCSI devices under Linux, you don't need to know the device ID number (unlike other versions of UNIX). As with IDE drives, there are no character devices for the drives, and partition numbers are appended to the drive device file.
Tape drives typically have at least two different device files. The primary device automatically rewinds the tape when you've finished reading or writing to it. The device with an “n” prepended to its name doesn't rewind the tape for you. Typically you would use this to write more than one archive on a tape.
tty devices are among the most numerous and the most confusing of all the files in /dev. Every time you log in or launch a new xterm, a tty device is assigned to the shell. This device is responsible for displaying the shell's output and providing its input. It is known as the controlling tty for that shell and its child processes. The device /dev/tty is a magic device that refers to whichever tty device is the controlling tty for that process.
Besides /dev/tty, there are three types of tty devices: consoles, serial ports and pseudo devices.
Console ttys are used when the keyboard and monitor are directly connected to the system without running the X Window System. Since you can have several virtual consoles, the devices are tty0 through tty63. In theory you can have 64 virtual consoles, but most people use only a few. The device /dev/console is identical to tty0 and is needed for historical reasons. If your system lets you log in on consoles 1 through 6, then when you run X Windows System, X uses console 7, so you'll need /dev/tty1 through /dev/tty7 on your system. I recommend having files up through /dev/tty12. For more information on using virtual consoles, see the article Keyboards, Consoles and VT Cruising by John Fisk in the November 1996 issue of Linux Journal.
If you have a terminal connected to a serial port or if you dial in using a modem, you'll use a serial tty device. There are a number of different serial devices which are used if you have a special card with many serial ports (ttyC*, ttyD*, ttyX* and ttyR*), but most people just use ttyS* for the normal serial ports (COM1 through COM4 under DOS).
This begins to get confusing, because there are also callout devices for each serial port. For each ttyS device there is a corresponding cua device. If you're only using the serial port for one purpose, it probably doesn't matter which device you use. To be able to both dial in to your machine remotely and dial out when you're home, be sure to use the tty version of the device to listen for incoming calls and the callout version to place outgoing calls. By doing this, you won't mess up someone who has dialed in by trying to dial out on the same line. (See “Serial Port Devices”.)
Pseudo tty devices are used when a login is initiated by launching a new xterm or by connecting to your machine via TELNET. Because you can have lots of windows open and many TELNET sessions going on at one time, you may need a lot of these devices. Hence, you should have a lot of files of the form /dev/pty*. Originally, Linux limited you to 64 pseudo terminals, but some people found that too restrictive, so you can now have up to 256 of them, using different major and minor device numbers. Making it a bit more complicated, there are actually two devices for each pseudo tty: a master and a slave. Thus, for each /dev/pty* file, there's a matching /dev/tty* file. Fortunately, you don't have to worry about the distinction other than being careful to create or delete them in pairs.
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Introduction to MapReduce with Hadoop on Linux
- RSS Feeds
- Weechat, Irssi's Little Brother
- New Products
- Tech Tip: Really Simple HTTP Server with Python
- Poul-Henning Kamp: welcome to
1 hour 24 min ago
- This has already been done
1 hour 25 min ago
- Reply to comment | Linux Journal
2 hours 10 min ago
- Welcome to 1998
2 hours 58 min ago
- notifier shortcomings
3 hours 22 min ago
4 hours 59 min ago
- Android User
5 hours 1 min ago
- Reply to comment | Linux Journal
6 hours 54 min ago
9 hours 43 min ago
- This is a good post. This
14 hours 56 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?