Software Systems
Spring 2005

For today, you should have:

1) worked on your project and written a project refinement

2) read Rosenblum and Ousterhout


Outline:

1) exam

2) Rosenblum and Ousterhout

3) file system interface

4) threads and locks, part three


For next time you should:

1) work on your project

2) read Raskin



File system interface
---------------------

What is the primary abstraction created by the file system?

What is the interface to that abstraction (for example, what is the
sequence of operations to read a byte from a file and write a new
byte)?


Most file systems provide interfaces at several layers:

1) user interface: what is the user's model of a file?
   What tools does the user have to interact with files?

   a) Graphical: file = document, click and drag.

   b) command line: file = sequence of bytes; ls, wc, awk, grep, etc.

   In most graphical systesm, documents belong to applications.

   In UNIX, many applications can operate on the same file.

2) High-level API

   print open(filename).read()

3) Middle-level API

   fopen, fscanf, fprintf, fclose

4) Low-level API

   creat, open, read, write, close

5) Really low-level API

   getblk, bread, bwrite

6) Really, really low-level interface

   SCSI
   
7) The hardware interface


The ioloop.c that I gave you demonstrates level 4:

#define FILE_MODE (S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH)
 
int main (int argc, char *argv[])
{
  int i = 0;
  int iterations;
  double x;
  FILE *fp;
  int fd;
  int n;
  char buf[] = "a";
 
  if (argc == 2) {
    iterations = atoi (argv[1]);
  } else {
    printf ("Usage: loop [iterations]\n");
    exit (-1);
  }

  fd = creat ("temp", FILE_MODE);

  for (i=0; i<iterations; i++) {
    n = write (fd, buf, 1);
    if (n != 1) {
      perror ("error");
    }
    n = fsync (fd);
    if (n != 0) {
      perror ("error");
    }
  }
  close (fd);
}

Each time you drop down a level, the number of lines of
code to perform the same task gets multiplied by 5-10.

What do you get in return?

This is an example of a common OS feature, a multi-layer interface.

In general, the higher levels provide

1) more abstraction, more work handled for you

2) more concise code

3) shorter development time

4) fewer errors

In general, the lower levels provide

1) detailed control, power

2) performance.


Power and performance are the sirens that lead
software projects to their doom!

And in some cases you don't even get the performance,
because the abstraction hides an algorithm that's
smarter than you.

Choose the highest level interface that can possibly
solve your problem, and only drop down if there is
no alternative.

Which brings us to a pedagogical question: if these
interfaces are so hot, why should we learn about their
implementations?

We shouldn't, unless they demonstrate an important concept
of OS design that is

1) intrinsically interesting,

2) likely to be applicable to other kinds of engineering.