First, make a fresh copy of your work thus far.
   cp -R xinu-hw7 xinu-hw8

Untar the new project files on top of this directory:
   tar xvzf ~brylow/cosc125/xinu-hw8.tar.gz

You should now see the new project files in with your old files. Be certain to make clean before compiling for the first time.

IPC (Interprocess Communication)

Our operating system requires one more form of interprocess communication to support a buffered I/O subsystem. Implement basic message passing with the system calls in system/receive.c, system/send.c, and system/sendn.c. The sendn() function is identical to send() except that it is non-blocking (does not immediately reschedule to a waiting receiver process).

You will need to add two additional fields to the PCB:

This system will allow only single word messages to be passed between processes, but I trust you will see how this could be expanded to more complex messages.

Create a main program that demonstrates message passing is working, perhaps with a message-based producer/consumer pair, called main-message.c, and make sure that it works when copied over main.c.

Loose Ends

Our operating system requires a few more helper functions to round out the semaphore subsystem. The tarball contains code for the functions system/sreset, system/scount, and system/freesem. These should work immediately with your other semaphore functions, but there may be adjustments to make if your semaphore code departed from the specification.

The fbDrawChar() function in your framebuffer driver must be made reentrant in order to support window pseudo-devices. A function is reentrant (can be safely entered multiple times, simultaneously) when it depends only on parameters, local variables, and constant global variables to do its work. Discounting the framebuffer memory region itself, this can be accomplished by replacing the function definition static void fbDrawChar(unsigned char c, int row, int col) with void fbDrawChar(unsigned char c, int row, int col, int fg, int bg) and checking that it does not depend on any volatile global variables.

Device Driver Subsystem

The code for a XINU device driver subsystem is provided for you.

A global device structure is defined in include/device.h, and initialized in system/devswitch.c. Make sure you understand what is going on in these files. This device table has been hardcoded with one framebuffer device (entry 0) and eight window pseudo-devices (entries 1 through 8). You may also see remnants of the serial and tty device types. The serial device would be for a hardware serial port, and the tty pseudo- devices would have the same relationship to the serial device as the windows have to a framebuffer device.

The code for high-level, device-independent I/O functions is provided for you. See system/open.c, system/close.c, system/read.c, system/write.c, system/getc.c, system/putc.c, system/init.c, and system/control.c. In all cases, these functions take a device descriptor (an index into the global device structure) and translate it into a call to the proper device-dependent function. Make sure you understand what is going on in these files.

Window Pseudo-Device Driver

A proper device driver typically consists of two parts, called the upper half and lower half of the driver. The upper half provides high-level functions for application programs to make I/O requests. The lower half communicates with the upper half via a shared request buffer, and communicates directly with the I/O device hardware, typically through interrupts. A pseudo-device driver lower half communicates not with actual I/O hardware, but rather with the device driver for some other piece of hardware.

The win/ directory contains a partial implementation of a pseudo-device driver for windows on the framebuffer device. The files win/winopen.c and win/winclose.c correspond to the high-level I/O functions open() and close(). The files win/winwrite.c, win/winputc.c, and win/wincntl.c correspond to the high-level I/O functions for device output and control.

Our windowing system will not have proper input functions, but you can imagine that these would point to the keyboard device driver in a more complete implementation.

You will be responsible for completing win/winwrite.c (the primary upper half output function,) and win/winoutproc.c (the lower half of the window driver.)