Lab46 Wiki

To explore and become more familiar with UNIX device files.

One of the important philosophical traits of UNIX is that of the following:

• Everything is a file.

As we've encountered so far, UNIX provides many facilities that aid us in the manipulation of files. Remember back during our exploration of the UNIX Shell, where we learned of the I/O redirection operators to manipulate the data streams? We are dealing with files, (redirecting the output to a file, reading in input from a file, etc.) just as we would by copying, editing, moving, or deleting.

Earlier in the semester we learned that in UNIX there are actually 3 different classifications of files:

• regular / ordinary
• directory / link
• special

Up to this point, we've primarily been working with regular files and directory files. We have always dealt with these files, be it on UNIX, Windows/DOS, the Mac, even in an office environment with filing cabinets.

However, on UNIX we've also got special files, which we've been briefly introduced to when referring to those “yellow files” in the /dev directory. But what makes those files “special”? And what purpose do they serve?

Well, with any computer we've got hardware components and peripherals. In Windows you may be familiar with the process of “installing drivers” in order to use a new device. Drivers are the instructions that inform the kernel of the operating system how to use the particular device. UNIX is no different: drivers are typically built into the kernel, or available as a form of “loadable kernel modules” (LKM) that can be inserted or removed from the kernel as desired.

But, like any device, one must establish some form of interface, so that the computer, when instructed by the kernel or the user, can operate the device and have it perform some reasonably useful operation. When you type a key on your keyboard, you'd ideally like for the computer to recognize such, right? Or when you save a file to your floppy drive, or load a program off the CD-ROM/DVD drive.

Well, the creators of UNIX paid more attention to the interface when it came to dealing with devices. Furthermore, it was decided to visualize various operating system characteristics as “devices” (be it software devices), so that they could share a common interface.

What's further, is that this device-access interface allows for both low-level and high-level access to devices (think of it like raw access- the straight 1s and 0s, and a more formatted interface). UNIX refers to these are block and character devices.

Block devices allow for raw access to devices, without interpretation from the kernel or supporting functionality (straight 1s and 0s).

Character devices are the formatted, civilized interface to a device - where there are structured commands and methods established for communication (such as “read”, “write”, “seek”, “abort”, etc.)

Using ls(1), we can look up the information on devices, and determine whether it is a block or character device. We can also view the usual ownership information, which establishes a simple form of access control, indicating who has access to the device, and what sort of actions they can perform.

What's more, is if our devices are represented as files, it means we can manipulate them just as if they were files: the regular file access methods apply. That means, just like regular files, we can open, read, write, seek, close, etc. our devices, OR send/receive information to/from them by reading or writing information to the appropriate device file.

Now how cool is that?!

As stated earlier, the special files in /dev contain entries pertaining to real physical devices/peripherals that are attached to the system. What sorts of things might we expect to find? Hard drives, mice, printers, audio devices, and more.

While as normal users we don't have much in the way of access to the hardware peripherals (the administrator / system typically manages those), we can still take a look around to get more familiar with things.

The hard drives attached to the system are a good example. While hard drive device designations vary from flavour to flavour of UNIX, let's take a look at one of the traditional Linux-style implementations.

At present time there are two significant device technologies on the market: SCSI (pronounced “scuzzy”) and ATAPI (sometimes abbreviated “ATA” or “IDE”). While an actual discussion of the merits/drawbacks of both technologies is beyond the general scope of this document (feel free to ask, if curious), just know that Linux establishes SCSI devices as “sd” (for SCSI disk) and ATAPI devices as “hd” (for hard disk).

Following this designation is the drive position on the bus (starting at “a”), and then the partition number (starting with “1”).

For example, on an ATAPI bus, the 3rd partition of the secondary master drive would be /dev/hdc3 (as ATAPI only allows 2 drives per chain- a master and a slave). So on an ATAPI system, the drive designations would be as follows:

Additionally, these devices can be subdivided, or partitioned, to allow for more organization of data.

For example, taking the first SATA drive, /dev/sda, and partitioning it, we would have:

• /dev/sda1 - first partition
• /dev/sda2 - second partition
• /dev/sda3 - third partition
• /dev/sda4 - fourth partition

Partitions are numbered from 1 and increment. Some systems may impose limitations on the arrangement or total quantity of partitions, others may not. For the end user, we merely can determine how the storage is allocated and accessed, and let the system take care of those other details.

See a pattern? The layout of devices tries to be relatively straightforward, so that less guessing is done on your part.

If interested, go and explore the drives in your computer, and read up on drive configurations, partitioning, etc. to get a better understanding of the organization of hardware beneath the filesystem.

Features implemented by the operating system also benefit from being made available as device files. Things like the terminal you use (more of an emulated piece of hardware), as well as sources of data (or lack thereof) are at our disposal.

Access to the system is made possible via the concept of the terminal- which is your set of eyes to the system. Back in the day, we had real terminals in the form of dumb terminals, which allowed us a means of viewing output, and entering input. As time went by, graphical systems came into being, and the idea of a terminal has shifted more into the realm of something “virtual”, or as software. Regardless, terminals are still critical to the use of UNIX systems (you use one whenever you log into a system).

Like a real terminal, you need the ability to enter input and view output. Well- how different is this from reading and writing? (standard file operations) By representing the terminal as a file, we can easily have a larger amount of terminals, without taking up anymore physical space by connecting a real terminal to the system.

So, each login is allocated its own terminal. We've sort of known this already, but now we're going to see why things work the way they do.

Remember back in our first lab, when we first used the who(1) utility, we took notice of the “MESG” column? And then, being able to modify that setting with the mesg(1) utility? We even played a little more with this in the UNIX Messaging Tools Case Study as we tested the actual properties of this functionality. Now, we're going to observe exactly why things work the way they do.

Okay.. so what? What's the big deal?

Now we should have a better understanding of how this particular functionality on UNIX works. With further exploration, you may find that much of the system operates based on existing properties and functionality.

Just like we can use environment variables to help us write incantations and scripts that apply to “everyone” (that which is friendly to portability), there exists a specific device which will always point to the specific terminal you're using.

Whenever you want to reference your terminal, you can access the file /dev/tty. You might say, it is the default STDIN, STDOUT, STDERR streams.

Two other important device files you should be aware of are: /dev/zero and /dev/null

• /dev/zero is a special file that acts as a source for zeroes. If you ever need some large quantity of the number zero (as integers), this file is key. For example, when blanking a drive, one often goes through a process of “zeroing” the drive.
• /dev/null is a special file that is often referred to as the “system bit-bucket”- if we desire to send something into oblivion, we can redirect it there. For example, if we don't wish to view the output of a particular command, we can send its output into oblivion.

This assignment has activities which you should tend to- document/summarize knowledge learned on your Opus.

As always, the class mailing list and class IRC channel are available for assistance, but not answers.