\\ Corning Community College \\ UNIX/Linux Fundamentals \\ \\ Case Study 0x9: Device Files \\ \\ ~~TOC~~ =====Objective===== To explore and become more familiar with UNIX device files. =====Background===== 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. ^ 1. ^|Do the following in the **/dev** directory:| | ^ a.|List some files in this directory| |:::^ b.|View the file type| |:::^ c.|List three different examples of a **block** device| |:::^ d.|List three different examples of a **character** device| ====Why files are good==== 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?! ====Hardware devices==== 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: ^ Position ^ Device Name | | IDE Primary Master | /dev/hda | | IDE Primary Slave | /dev/hdb | | IDE Secondary Master | /dev/hdc | | IDE Secondary Slave | /dev/hdd | | IDE Tertiary Master | /dev/hde | | IDE Tertiary Slave | /dev/hdf | | First SATA/SCSI Drive | /dev/sda | | Second SATA/SCSI Drive | /dev/sdb | | Third SATA/SCSI Drive | /dev/sdc | | Fourth SATA/SCSI Drive | /dev/sdd | | First Xen Virtual Disk | /dev/xvda | | Second Xen Virtual Disk | /dev/xvdb | 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. ^ 2. ^|Do the following:| | ^ a.|Using the **df**(**1**) command, list the filesystems currently in use by the system| |:::^ b.|What device is **/** mounted on?| |:::^ c.|What about **/home**?| |:::^ d.|How about **/tmp**?| |:::^ e.|Where is the system swap?| |:::^ f.|What type(s) of storage does Lab46 use for its data?| 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. ====Software devices==== 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. ^ 3. ^|Let's discover a little bit about our terminal:| | ^ a.|Log in at least twice.| |:::^ b.|Run the **who**(**1**) command, locate the terminals (TTYs, PTYs) you're using| |:::^ c.|Using the **tty**(**1**) command in each terminal, determine the exact PTY of each session| 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. =====Procedure===== ====User-to-user messaging==== 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. ^ 4. ^|Locating your current terminal via the **tty**(**1**) utility:| | ^ a.|Change into the directory where your terminal file is located| |:::^ b.|Do a long listing with **ls**(**1**)| |:::^ c.|What are the permissions on your terminal file?| |:::^ d.|Do a who(1) or run mesg(1)- what is your current messaging status?| Okay.. so what? What's the big deal? ^ 5. ^|Do the following:| | ^ a.|Toggle your messaging capability with **mesg**(**1**)| |:::^ b.|List your terminal device file and view the permissions.| |:::^ c.|How has it changed from before?| |:::^ d.|Why does this allow/prevent others from messaging you?| 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. ====The terminal pointer==== 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. ^ 6. ^|Do the following:| | ^ a.|Using **cat**(**1**), output the contents of: **/etc/motd**| |:::^ b.|Do the same, but redirect output to: **/dev/tty**| |:::^ c.|What is going on here?| ====Something and nothing==== 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. ^ 7. ^|Do the following:| | ^ a.|Using **cat**(**1**), output contents of: **/etc/motd**| |:::^ b.|Do the same, but redirect output to: **/dev/null**| |:::^ c.|What did you type?| |:::^ d.|How might **/dev/null** be useful?| =====Conclusions===== All questions in this assignment require an action or response. Please organize your responses into an easily readable format and submit the final results to your instructor. Your assignment is expected to be performed and submitted in a clear and organized fashion- messy or unorganized assignments may have points deducted. Be sure to adhere to the submission policy. When complete, electronically submit your assignment by filling out the following form: http://lab46.corning-cc.edu/haas/content/unix/submit.php?cs9 As always, the class mailing list is available for assistance, but not answers.