See $cs644/proj/proj.txt, lpdriver.txt, ipc.txt, plus subdirectories.
Proposal due next Tuesday, May 4
Implementation due following Tuesday, May 11 (last day of this class)
An IPC Datagram Service: IPC that uses a network-like API
Port Numbers. The way that TCP and UDP subdivide the system-wide networking capability is to support the idea of “ports.” Each system has a sequence of port numbers that provide rendez-vous points for senders and receivers. We will follow this lead.
One process does a dgram_receive for a certain port number, and blocks if nothing is available. Another process does a dgram_send to that port, and the message is exchanged. The messages are all of fixed length, for simplicity.
The dgram_send can come first, and in our simple system, datagrams are queued in the kernel for that port until a dgram_receive comes in for the matching port.
You can see there is similarity of this system to the send/receive just done in hw4. You can start from your solution or the class solution for hw4.
Clients and servers: A server is a program that (usually) long-lived and offers a particular service to clients. To get the use of the service, the client sends a datagram with the request to the server’s port, and the server responds with another datagram with the result. Sample services: console-printing, name-value, locking. You implement two of these.
How to get started: Start from a solution to hw4, plus provided Makefile, stubs in proj/ipcsupport. Borrow code from kernel init, send and receive of hw4 and morph into init, dgram_send, dgram_receive, but watch out for differences in behavior. Note that you need to copy the datagram from the sender into kernel memory, since the sender may reuse its own buffer after return from dgram_send. You could use buffer pools (Chap 15), or just getmem. Be sure to free any memory you obtain, when the datagram is delivered.
Line Printer Driver, a Xinu device driver, so a UNIX-like device driver, and in particular similar to the output side of the Xinu tty driver we’ll soon study.
System setup: SAPCs 12 and 14 have bi-directional parallel ports added on as LPT2. Thus they can accept parallel data and behave like a printer. The printer emulator program is provided as printem.lnx (a standalone program, quite small.) It just echoes the “printer” output on the console line.
SAPC 11 LPT1 (output only) is connected to SAPC 12 LPT2 (bi-directional) by a parallel cable, and similarly SAPC 13 to SAPC 14. We can run a program on SAPC11 that outputs to LPT1, and this output is “printed” by printem.lnx running on SAPC 12. Or run on SAPC13 and SAPC14.
A provided program testlp.lnx can be run on SAPC11 along with printem.lnx on SAPC12 (or SAPC 13, SAPC 14) to show that this idea works. Your job is to write the lp device driver for Xinu for output to this device, so that a Xinu program can be run on SAPC11 and “print” using printem.lnx on SAPC12. See programs and scripts in proj/lpsupport.
Hardware: see $pcinc/lp.h: LPT1_BASE = 0x378, start of little block of 3 i/o ports:
LPT1_BASE
+ LP_DATA = 0x378: 8 bit data port, aka PDR (printer data register)
LPT1_BASE
+ LP_STATUS = 0x379: 8 bit status port, aka PSR
LPT1_BASE
+ LP_CONTROL = 0x37a: 8 bit control port, aka PCR
Printer protocol: output a byte via PDR, send a strobe signal via PCR. The printer (after a while, when it’s ready for more data) sends back an ACK signal which causes the printer interrupt on IRQ7. When the printer interrupt comes in, the driver can send another byte. See $pcinc/lp.h and testlp.c.
How to get started: Read Chap. 11 and 12 of Comer, concentrating on output, since the printer only does output, no input of data. Note that $xuker/conf.c already has the needed entries for lp. Copy the provided files in proj/lpsupport. All you have to do is edit the stubs in lp.c to do the needed actions. Before you start coding, try out testlp.lnx vs. printem.lnx to make sure the printer emulator and cable is working.