HW1: Standalone I/O package for the SAPC
Assigned: 16 September 2015 Part 1 Due: mid-night 22 September 2015
Part 2 Due: mid-night 3 October 2015
1. Introduction
For each hw in this class, the students should make a subdir of the same name, e.g. hw1_part1, hw1_part2, 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 and any special notes. The style of the program is important. See C coding guidelines.
2. Running the provided testio.lnx using remote gdb (Part 1)
You can find an example of a remote gdb session on the SAPC in http://www.cs.umb.edu/~cheungr/
cs444/gdb_script.pdf and a good summary of gdb commands in http://www.cs.umb.edu/~cheungr/ cs444/gdb.pdf.
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_part1/remgdb-testio.script. This part is due earlier than the rest.
3. Just short of an operating system–a standalone I/O package for the SAPC (Part 2)
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 hw1_part2 as follows:
- 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 cs310. Once you have a variable of type Queue, it’s easy to get a Queue
pointer by using &.
- 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.
- 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.
- 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.
4. Testing
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 test runs and leave the file created (testio.script) in your hw1 directory.
The following files need to be in your cs444/hw1_part1 directory:
- i) README: with authorship statement for sure.
- ii) remgdb-testio.script
iii) testio.script
The following files need to be in your cs444/hw1_part2 directory:
- i) lpdriver.txt
- ii) tty.c and tty.h
iii) testio.script