The project for the current term is to implement (on a simulated disk) a file system based on the design explored in the
lectures. This project is divided into four pieces.
You must read and follow the
Project Expectations. Study the grading
sheet given below.
This is Part 0 of the project for this term. You are expected to study and modify the
source code files given in source.tbz and achieve the functionality described below. Do not use source code files
of others or even those of mine but from prior terms.
Be Considerate. Do make sure that you are not using up too much space
(say > 10 MB) in your home directory. The following will show your disk
space usage: du -s ~
1. Learn Unix Commands
Coming into the course, you are expected to be comfortable with
Unix commands. Try all the commands of
the
Minimal List of Unix Commands You cannot claim to be
Unix-familiar unless you have used them all a few times. Use
script (read man script) to demonstrate that you
invoked the commands. A few commands cannot be run unless
you are super user; for such commands, just capture its message. Turn
this file in as a file named cmdsTried.txt.
2. Studying a Program
By the time P1 is due, we would have covered the process management necessary for this project.
The tar ball source.tbz is a collection of files given so
that (i) you can get started quickly with our project, and (ii) you can see the style of how larger systems programs are written. Download source.tbz from the link
above. In a Linux environment, it can be un-tar-ed as follows: tar xvvfj source.tbz
The functionality of source.tbz is
described in What Is Given. Some details of the code are/were explained in the lectures and in
ReadMe.txt. Study the provided source code
so thoroughly that you could have written it. At this point, you can focus on the files fs33types.hpp and shell.cppThen, answer the itemized questions below in a file named
answers.txt.
- The following are standard library routines:
dup2, creat, pipe, fork, pthread_create, system, printf
Look up their
functionality in both the Stevens' book and the on-line man
pages. Describe their functionality briefly, one sentence each,
in your own words.
- In the file
shell.cpp, what is the point of the last line of the function invokeCmd?
3. Learn to Use GDB
Coming into the course, you are expected to be comfortable with gdb.
Debugging large programs requires the construction of (extra) observer
methods. Using gdb or some other debugger is not as
effective as invoking observers and studying their output in a
peaceful place ("under a tree"). Nevertheless, gdb can be useful as a
last resort, and you must be able to use it well.
- Start
script. Make P0 as given. Run our program P0 through gdb.
- Set a breakpoint at immediately after
main() Examine the values of
buf, arg, types, nArgs while tracing down the code
- Type in a command to our shell, such as
mkfs D1. Trace the
execution from the above breakpoint onwards by single stepping until
you reach the end of the fucntion invokeCmd.
- Type in
!ls request and trace. Do you notice a difference?
- End the script. Turn in this script as a file named
gdbSession.txt
4. Additions and Improvements
Part of large program development is independently, but wisely,
deciding what to do for certain "erroneous" situations. Should we ask
the professor for what to do for every possible error you can think
of? [Answer: No. You think about it. You take a reasonable
action. You document this in your source code, and in
ReadMe.txt. And, be ready to defend your choice should it
be questioned.] Remember that one of the goals of CEG 433/633 is to
make you think about larger programs. Part of this is to supply
missing, but needed, details in the problem description.
As given, the files of source.tbz implement the following.
fs33% mkfs D1 - creates an initially empty file volume on the simulated
disk named
D1.dsk. At this point, we do not need to discuss all the specifics anout the structure of the disk
fs33% ls - prints a listing, much like the Unix
ls -lisa, of
all the files in the root directory of the current file
volume.
Here is a stdTestScriptP1.txt. Use it as in ./P0 < stdTestScriptP1.txt .
4.1 Redirection
Implement redirection for the given shell as discussed in class. Use the operator > to redirect the output of a command into a file on the host's file system. It is safe to assume that the redirection operator appears only once in the command line.
4.2 Piping
Implement piping as discussed in class for commands executed on the host. For example, the command !ls | !cat executes both commands on the host. However, the piping needs to be performed in your shell! It is sufficent if your shell supports single piping, i.e. the concatenation of two commands. Bonus points are available if you achieve multiple piping.
4.3 Executing in the background
Allow your shell to execute commands in the background using the &. The command prompt should return immediately after issuing the command no matter how long the execution takes. It is safe to assume that the character & only appears once in the command. Your shell should support the execution of all types of commands in the background, i.e. local commands operating on the virtual file system as well as commands running on the host.
4.4 A Simple Test Session
Only the additional elements compared to the given source code are described below. Add
these appropriately to the test script. Our path name syntax is
the same as Unix path names. Obviously,
not every arbitrary string is a valid path or name. Also, the dot and the
dot-dot are not permissible as arguments in some contexts below.
Nevertheless these commands must be robust.
- fs33% ls > test
- lists the contents of the current directory of our own file system and redirects the output into the file
test of the local directory of the host's file system.
- fs33% ls | !cat
- pipes the output of
ls into the local command cat.
- fs33% !cat test
- shows the contents of the file test of the host's file system (which should contain the output of
ls if previously executed as above).
- fs33% !sleep 15 &
- waits 15 seconds (since it is executed in the background the command prompt should be available immediately, though).
5. Turn In
All projects need to be submitted via
Pilot.
|
|
| Extra credit points are awarded in recognition of good work and
extra work, in addition to the max possible points. Quality is
subjectively judged. Merely turning in a file will not receive
full score. Some items have a cascading effect. |
| Item description |
Max |
Points |
ReadMe.txt exists with content as described in Project Expectations |
5 |
|
Your testscript.txt is designed so that all the functionality
is demonstrated, including robustness. |
5 |
|
Your program successfully navigates your own testscript.txt.
( If yours is too simple, we may run it through our script that you
will get to see only after the due date.) |
5 |
|
cmdsTried.txt shows use of at least 10 of
Minimal List of Unix Commands |
5 |
|
answers.txt |
10 |
|
gdbSession.txt |
10 |
|
ls > test |
20 |
|
ls | !cat |
20 |
|
!sleep 15 & (background execution) |
20 |
|
| Bonus points 25, if you implement multiple piping, i.e. you can set up a piped command consisting of more than two commands. |
B25 |
|
Files were not submitted using pilot = minus 10
points |
-10 |
|
| Total |
100 |
|
