15-410 Project 4 Pipes

If you choose to do the pipes project, here is what we are looking for.

Pipes Overview

A "pipe" is a special kind of Unix file which allows for communication between pre-arranged groups of tasks. Each pipe has a "write end" (a write-only file descriptor), and a "read end" (a read-only file descriptor). Bytes written onto the write end appear, in order, at the read end. Pipes, as other Unix file descriptors, are inherited across fork() and exec(), so a task (such as a shell program) can create a pipe and connect two tasks to the write and read ends, causing them to communicate with each other.

Kernel Changes

The pipes project will require you to add to your kernel:

• Per-task file-descriptor arrays, shared on fork() and inherited across exec(),
• pipe(), dup2(), read(), write(), and close() system calls (see Unix manual pages),

and will also require you to retrofit:

• The user-level print() and readline() subroutines will need to be re-cast in terms of read(0, ...) and write(1, ...).
• Your current kernel implementations of print() and readline() will need to be adjusted so they can be invoked via calls to write() and read(),
• exit() will need to invoke close() as appropriate.

Design

You will probably want to make your pipes "record-oriented" in the sense that a read() call will usually return as many bytes as a previous "matching" write() call rather than the total number of bytes which could be read from the pipe. When this is not possible, however, bytes must not be lost from the pipe's data stream (they must be available to a later read()). Console I/O will continue to be "record-oriented" around lines.

Observe that as a result of your changes readline() will have a new legal return value. Interesting...

Have Fun!

Make sure to have some fun with this project. You've earned it, right?

If you have lots of extra time, feel free to explore the deadlock implications of pipes. What can/should you protect against? How?

[Last modified Monday November 22, 2004]