CS170 Lab #3 -- KOS Pipes

  • CS 170 Lab 3
  • Rich Wolski and James Plank
  • Your Aunt Heloise, of course, has a few thoughts to share
  • URL: http://www.cs.ucsb.edu/~rich/class/cs170/labs/kos_pipe
  • Directory: /cs/faculty/rich/public_html/class/cs170/labs/kos_pipe
  • Due: Wednesday Dec 7th, 2022 at 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 ksh and/or pipe-4.c and connect processes with pipes.

    As before, the outcome of the previous KOS labs (Lab 1 and Lab 2) 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 Lab 1 or Lab 2 code while you work on Lab 3, 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 (it is the same as the one for Lab 2). You should also use the the same version of simulator_lab2.h that you used for Lab 2. If you are using your own makefile, then load 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 get an error back from the write (choose one that you like). We are not going to deal with catching SIGPIPE signals. Similarly, if a process is blocked writing to a pipe and the read end goes away, the writing process should unblock and get back an error. If a process is 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.

    To help, I've put a binary you can find in /cs/faculty/rich/cs170/test_execs/ksh. The binary ksh 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 test codes since you can see what is happening both inside and outside the test. That is, the supplied version of ksh is not definitive and you should not consider it as being the exclusive test as to whether your Lab 3 is working or not. It is there simply to help with testing.