CS 232 Project 1: Reporting State Information

Overview.

This project is to write a C++ program named hostinfo that reports Linux kernel state information. Your program will create instances of several C++ classes (which you will also write), each designed to inspect a particular part of the kernel's state, and then use that instance to report the state of that part of the kernel.

Details.

Linux maintains its state information in a variety of data structures that are known as kernel variables. The declarations of these data structures are generally stored in /usr/src/linux/, mostly in the include directory.

To provide an easy-to-use interface to this state information, Linux provides a pseudo file system called /proc. /proc is a pseudo file system because the "files" in it are actually programs that read kernel variables and report their values as ASCII strings. Thus, a C++ program can "open" one of these "files" and read from it as if it were a text file. You should read the man pages for proc, as well as take time to explore the contents of the pseudo-files in /proc.

Your program should allow a user to type:

  hostinfo [switches] 

1. --cpu or -c, report CPU vendor, model number, and speed.
2. --int or -i, report the number of interrupts generated by the timer, keyboard, USB or PCI devices, mouse, hard drive, and CD-ROM drive.
3. --mem or -m, report total memory available, and memory that is currently available (free).
4. --boot or -b, report the elapsed time, the number of processes created, and the number of context switches since the system was booted.

   hostinfo -i --mem

   hostinfo -m --cpu -b --int

To process these command-line switches, your main function will need to use its argc and argv parameters. If you have not used these before, see any good C or C++ book for information on how to do so.

To provide these services, your program must use four classes: CPUInspector, InterruptInspector, MemoryInspector, and BootStatsInspector, plus a fifth Inspector class in which you store attributes/operations common to the first four classes.

The constructor for each class should open the pseudo file containing the information it reports. Since each subclass will have to open a pseudo-file, the code to actually open the file and the ifstream to it should be stored in the superclass (i.e., Inspector) constructor.

Each class should provide a separate accessor method for each attribute it retrieves. For example, the BootInspector class should provide getElapsedTime(), getProcessesCreated(), and getContextSwitches() methods. Each method should return its result as a string.

Note that the values returned by some methods (e.g., MemoryInspector::getTotalMemory()) should be the same from invocation to invocation of the method, while the values returned by other methods (e.g., MemoryInspector::getFreeMemory()) may change from invocation to invocation. Your classes should take advantage of this, and only re-open the file containing a kernel variable's value if its value is one that can change during program execution. (Hint: read static values once, in the class constructor, and define an accessor method to report those values; report dynamic values by reading them anew from the pseudo-file; where feasible, let the subclasses inherit values and methods from the Inspector class).

Plan of Action.

0. Read up on argc and argv, and explore /proc using cd and cat.

1. Get a skeleton program working that correctly processes command-line switches, plus a Makefile to compile and link it. (Hint: Process the entire command-line before doing anything else, using the switches specified to set bool variables. Then use those bool variables to control your program.)

2. Design your Inspector class hierarchy, specifying which methods go where.

3. Build and test the Inspector superclass.

4. Build and test each subclass.

5. Modify your program to make use of your classes.

6. Thoroughly test your system.

7. Print and fill out the top part of the project project gradesheet. Then complete the rest of the turn-in requirements that are discussed below.

Feel free to discuss the project, the Unix manual pages, and the /proc pseudo files with myself or your classmates. You are not to look at the code of anyone else.

Your program should be reasonably efficient in terms of its use of both time and space. It should also be fully documented: with an opening (header)

• Each class should be stored in its own .h file. Non-trivial methods must be stored in a separately-compiled .cpp file.
• Each file should have an opening comment that gives all of the usual information (who, what, where, when, and why).
• In addition to the .h file, each class must have a separate .doc file that is a copy of the .h file, in which a comment precedes each method declaration giving a functional specification (e.g., natural language description, parameters, precondition, return-value or postcondition) for that method. (Hint: Create this last, when your classes are stable, so that you don't waste time rewriting your documentation.)
• As in any project, you are to use descriptive identifiers, and in-line comments that explain any 'tricky' parts.
• All output should be clearly formatted and labeled for easy readability.

Turn in: The project grade sheet (you need to fill out the top part), attached to a copy of each file you create for the project, plus a hard copy of a script file, in which you

1. Use make clean and then make to successfully compile your program; and
2. Execute your program as necessary to show that the various combinations of command-line switches all work (including executions with malformed switches). Example: run another program in the background between two executions of your program, to show that your free memory inspector works as it should.

Due date: Wed, Feb. 8, 11:59 p.m.

CS > 232 > Projects > 1