HW1: A Standalone I/O package for the SAPC
Assigned: 9 September 2013 remgdb-testio0.script Due: midnight 22 September 2013
Rest Due: midnight 1 October 2013
For each hw in this class, students should make a subdir of the same name, e.g. hw1, and put everything there you want the grader to look at. Supply a README file for the grader to read first, and include in it your authorship statement (see Honesty.html) and any special notes. The style of the program is important. See C coding guidelines.
Note that this document uses $pcex and $cs444 to denote important directories for this course. The pcex environment variable is defined by the ulab module you should be loading from your .cshrc. See the instructions at the ulab home page, which also has a link for the pcex directory, and others. Similarly, we use $cs444 to stand for class home page at http://www.cs.umb.edu/cs444 and in the filesystem at /courses/cs444/public_html. For easy access locally, add the line “setenv cs444 /courses/cs444/public_html” to your .cshrc (and log out and back in). Then “ls $cs444/hw1” should list the hw1 files, including this one, hw1.html, when you are logged in on ulab.
You can find an example of a remote gdb session on the SAPC in $pcex/gdb.script, and a starter gdb tutorial and a small gdb cheatsheet linked to the ulab home page. All source files needed for this homework assignment can be found in $cs444/hw1. First study testio-orig.script and reproduce it, noting the behavior that needs to be fixed by your work for problem 3. Then reproduce remgdb-testio.script, that is, run the provided testio.lnx under control of remote gdb with several breakpoints and "next" commands, and successfully enter input in the console window. Additionally, display the contents of buf after it has been filled in. Leave this in hw1/remgdb-testio0.script. This part is due earlier than the rest.
By "standalone" we mean there is one and only one program running on the machine, so the whole machine is owned by that program.
We start from an almost-complete but imperfectly coded device-independent standalone I/O package provided in $cs444/hw1. Fix it up and leave them in your cs444/hw1 as follows:
a. Given a character queue module that allows multiple queues, in subdir queue:
init_queue(Queue *q, int max_chars); make a new empty queue, filling in *q
int enqueue(Queue *q,char ch); enqueue char ch on q, or return -1 if can't
int dequeue(Queue *q); dequeue a char and return it, or return -1 if can't
int queuecount(Queue *q); return # chars currently in queue q
Use it to replace all the ring-buffer code in this I/O package with proper queues, one Queue for the readqueue, another for the writequeue, etc.Use just 6-char Queues so you are sure to test it fully. Don't edit or replace queue.c, just *use* it.
The code should now be easier to understand. Note: we don't have malloc in the SAPC library. Therefore you will need to use "Queue" type variables to hold the queue state, not Queue * pointers + malloc'd space as often done in cs240. Once you have a variable of type Queue, it's easy to get a Queue pointer by using &.
b. Type ahead is a feature that enables users to continue typing regardless of the computer operation. If the receiver is busy at the time, it will be called to handle this later without dropping characters. The original read function takes in only the characters before the read function is called. A longer delay loop before the read function is called will cause more characters to be read. We want to fix the read function such that it will read in all the characters the user types ahead.
c.
The write function only polls--let's make it interrupt driven too. Set up an
output queue for each port, again only 6 chars capacity. Chars from a user
write call are enqueued, or, if the queue is or
becomes full, the caller has to wait for space to show up. Set up a second
queue for echoes, and output preferentially from the echo queue.
d. Testing is always an important part of any code writing. Generally, you need to write many tests. Here, I've provided a comprehensive test for you, testio.c. Your hw1 submission should include the output of a test run. Use the 'script' command to capture the output of your final test run and leave the file created (testio-final.script) in your hw1 directory.
3. Device-Independent
I/O
Consider how to add the LPT1 device (write-only) to this system. See $pcinc/lp.h for the hardware header for this device. What edit is needed for ioconf.c? Invent function names to go in devtab and a filename for the lp driver code, corresponding to tty.c for the TTY devices. What functions would be implemented in this new file? You don't need to code this up unless you want to, just invent function names and file names and discuss, in lpdriver.txt.
Note: because this is a standalone I/O package, and not a real OS, it is allowable and necessary for the waits to be busy loops. Once we are writing OSs, this will be a great crime, wasting the CPU that could be used by another program.
Delivery
The following files need to be in your cs444/hw1 directory. We will build and run your code, and read your edits.
README: authorship statement, notes to grader, late days if needed
remgdb-testio0.script
tty.c and tty.h,
and all the other provided files for building testio.lnx
makefile (added queue/queue.opc to IO_OFILES as
indicated in comment)
testio-final.script
lpdriver.txt