Assignment 7, due Oct. 11
On all assignments, your name must be legible as it appears on your University ID card! Assignments are due at the start of class on the day indicated (usually Friday). Exceptions will be by advance arrangement unless there is what lawyers call "an act of God" (something outside your control). Homework must be turned in on paper, either in class or in the teaching assistant's mailbox. Never push late work under someone's door!
There are 17 times 255 times 3 (that is 13005) sectors on this disk. Disk addresses on this device have 3 components: cyl -- cylinder, surf -- surface and sect -- sector. Which is the most significant component, which is the middle
a) Which is the most significant component of the disk address, which is the middle (in significance) and which is the least significant? (0.4 points)
b) A linearized disk address on this disk will be a sector number between 0 to 13004. Give the expressions to extract sect, cyl and surf from a linearized sector number num. (0.6 points)
A Question: When can the system safely copy data directly between the user's buffer and the disk without using any intermediate system buffers? Consider expressing your answer in terms of constraints on the file position, sector size, buffer address, buffer length, etc. (0.5 points)
a) Suppose a disk request is already in the queue to write disk address a, and the user asks the driver to enqueue a new write to disk address a. For maximum performance, what should be done? (0.5 points)
b) Suppose a disk request is already in the queue to write disk address a, and the user asks the driver to enqueue a new read from disk address a. For maximum performance, what should be done? (0.5 points)
c) The computation needed to determin if a request is already in the queue is simplified if the disk request queue is sorted by disk address instead of being a simple FIFO queue. Aside from supporting the optimizations hinted at above, what is the primary reason a disk driver might keep the queue sorted.
You will have to modify a version of mush.c as modified by the requirements of mp3. If you have not solved mp3 yourself, you should do so even if you end up using the MP3 solution distributed to the class.
Modify mush.c so support the following features:
Consider this example:
loop echo just once while setenv first nonblank setenv second nonblank setenv third nonblank loop echo done three times setenv first $second setenv second $third setenv third while $first
You should be able to nest loops at least 8 levels deep, but you need not enforce a limit on the nesting (there are solutions that require an array indexed by nesting level, and others that do not require this). You will find that the fseek() command or one of its cousins plays an important part in this assignment.
As always: You are responsible for improving the code. The guidelines in the Manual of C Style apply. Failure to maintain a legible record of authorship in the program heading is a major problem. Your code must be clear and legible when printed on paper. Break long lines so that you are not at the mercy of automatic line wrapping, and do not write overly verbose comments or comments that state things that are obvious from reading the code.
Submit your solution through the normal channels: That is, you should use the submit program for the course c_112 and the assignment mp4. The source file you submit should be called mp4.c. Variation from this will be penalized.
Several students asked if they need to keep a copy of the loop body in some auxiliary place. The answer is no. If the source file is seekable, the an fseek() call can re-position the source file to the top of the loop body for each iteration. If the source file is not seekable, you are not required to be able to execute loops. (An error message would be appropriate in that case.)
Several students asked if they needed to write special code to make mp4 execute scripts from disk. No! Just write your test script as a file and use I/O redirection to make mp4 read from that file, for example:
[jqstudent@serv15 hw]$ a.out < mp4testscript
A student asked: "My program seems to work, but then it goes into an infinite loop!" The most obvious response is to ask these questions: "What does mush do when it encounters an end of file? And, did the test script end with an exit shell command? Recall that MP3 asked you to add that command.
A student asked: "Why, when I run my solution from a test script file, do I get this strange output in addition to the output I expected?"
Each of those > characters was a prompt output by your test script prompting for a line of input from the terminal. This is outside the specification of what you were supposed to do, and during debugging, it may be useful (you can tell how many times your shell prompted for input). If you want to suppress this prompting, you can add logic to your shell to test if the current device is seekable. If it is not, it is probably an interactive keyboard, and you should prompt. If it is seekable, it is probably a disk file, and you should not prompt.