User Tools

Site Tools


Sidebar

projects

wcp1 (due 20220824)
adm0 (due 20220831)
ntr0 (due 20220831)
pct1 (bonus; due 20220831)
wcp2 (due 20220831)
pbx0 (due 20220907)
pct2 (due 20220907)
pct3 (bonus; due 20220907)
wcp3 (due 20220907)
wcp4 (due 20220914)
pbx1 (due 20220915)
pct4 (due 20220915)
wcp5 (due 20220921)
pbx2 (due 20220922)
pct5 (bonus; due 20220922)
gfo0 (due 20220928)
wcp6 (due 20220928)
pct6 (due 20220929)
upf0 (due 20220929)
pct7 (bonus; due 20221005)
upf1 (due 20221005)
wcp7 (due 20221005)
bwp1 (bonus; due 20221019)
pct8 (due 20221019)
usr0 (due 20221019)
wcp8 (due 20221019)
pct9 (bonus; due 20221026)
wcp9 (due 20221026)
gfo1 (due 20221102)
pctA (due 20221102)
srf0 (due 20221102)
wcpA (due 20221102)
pctB (bonus; due 20221109)
wcpB (due 20221109)
mtf0 (due 20221110)
pctC (due 20221116)
wcpC (due 20221116)
wpa0 (due 20221117)
bwp2 (bonus; due 20221201)
pctD (bonus; due 20221201)
wcpD (bonus; due 20221201)
pctE (bonus; due 20221207)
wcpE (bonus; due 20221207)
gfo2 (due 20221208)
EoCE (due 20221219)
haas:fall2022:unix:cs:cs6


Corning Community College


UNIX/Linux Fundamentals



Case Study 0x6: 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.

In addition to df(1), checking the contents of the /etc/fstab file can yield some information about the filesystems available.

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

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.

haas/fall2022/unix/cs/cs6.txt · Last modified: 2013/10/08 09:14 by 127.0.0.1