CS170 Lab #4 -- KOS Pipes

  • CS 170 Assignment 6
  • Rich Wolski and James Plank
  • URL: http://www.cs.ucsb.edu/~rich/class/cs170/labs/kos_pipe
  • Directory: /cs/class/cs170/labs/kos_pipe/
  • Some Helpful Hints from Aunt Heloise that may prove insight inducing
  • Due: Tuesday, March 18th, 11:59 PM
    The explanation in this lab is simple. Implement the system calls dup(), dup2() and pipe(), and make sure that close() works correctly with these. When you're done you should be able to use jsh and connect processes with pipes.

    As before, the outcome of the previous KOS labs (lab2 and lab3) contribute substantially to the success of this one. In "real life" it would probably go this way as well. First, you'd get the I/O subsystem working, then you'd get some rudimentary process management happening, and then you'd start with the good stuff. As such, if you find yourself fixing bugs in your lab2 or lab3 code while you work on lab4, you are having the true operating systems experience.

    Compilation and Linking

    In the kos_pipe directory you will find a Makefile that will link your code with the version of simulator.h that you will use for this lab along with:

    Subtleties

    You'll have to deal with certain events correctly. For example, if you write to a pipe that has no read end, your process should die quietly (i.e. we're not going to deal with catching SIGPIPE signals). If you are blocked writing to a pipe and the read end goes away, your process should die quietly. If you are blocked reading from a pipe and the write end goes away, the read() system call should return zero. If you have written bytes to a pipe, but they never get read, that's ok -- make sure it isn't a problem (i.e. a memory leak). We would also like the semantics of pipe reading/writing to be like Linux. For example, if one process does write(p[1], buf, 10) and the process on the other side of the pipe does read(p[0], buf, 20), the read() call will return with 10 bytes.

    Test executables can be found at

    /cs/faculty/rich/cs170/test_execs/.

    Of particular interest should be the code pipe_test.c. Note that we are not changing the KOS bootstrapping mechanism to be able to launch more than one program. As a result, to test your OS, the program that you launch will need to fork and exec subprograms (e.g. in the same way that your Jshell does).

    Speaking of Jshell -- the easiest way to develop your solution to lab4 is to cross compile your implementation of Jshell for KOS. There are a couple of issues to understand when doing so. First, the version of the cross compiler that we have installed for Dec Ultrix does not include all of the header files that one might expect to find in a modern Linux system in the same location. Additionally, some of the code that is generated is not recognized by the simulator. The header file < string.h >, for example, allows access to the memset(), memcpy() routines and their use causes the simulator to fail with an internal assertion. You may need (as I did) to write your own versions of these routines to get your shell to work.

    To help, I've put a binary you can find in /cs/faculty/rich/cs170/test_execs/jsh. The binary jsh should run in your simulator as long as you do not attempt to redirect the shell input or output (you have no file system). There is no guarantee that this version is bug free and the source code will not be available. Thus the best approach is to work with your own shell since you can see what is happening both inside and outside the shell and debug what ever problem you may be seeing. That is, the supplied version of jsh is not definitive and you should not consider it as being the exclusive test as to whether your lab4 is working or not.