6.033 one-pager 2 notes

[Douglas De Couto <decouto@lcs.mit.edu>]

Here are some notes written by the TAs after reading the one-pagers
for last weeks assignment.  Hopefully you will find them usefule and
informative.  If you have any questions, please speak with your TA.

---------------------

1. This was a hard question, so don't be discouraged if you found it
   difficult. 

2. From now on, please make sure that everything you put down on your
   one pager you can justify. If you are not 100% sure about how
   something works, don't put it down as though you are. Don't assume
   that how you think it works is actually how it works, and then
   write your paper based on that assumption. Try and find out from
   the paper, or ask the TAs. For example, sequential I/O has nothing
   to do with limitations on file sizes.

3. Some of you wrote that the stream I/O abstraction was not a good
   one, and that Dennis and Ritchie lacked any insight into the future of
   technology -- you wrote that if they had an idea about what sort of
   hardware was coming, they would have chosen different abstractions.
   But Dennis and Ritchie knew exactly what they were doing.  They had
   worked on large projects such as Multics, which actually had many
   different forms of I/O (including streams, by which the UNIX design
   was influenced).  Also, they had seen and used computers with more
   capabilities: larger memories, disks, etc.  It just so happened that
   their particular computer, the PDP-11, was on the low end of the
   spectrum.
   
   Also, the stream abstraction has proven itself as a highly useful
   and convenient one: most operating systems include stream I/O to
   files and devices, including MacOS, Windows NT, and current
   versions of UNIX and its derivatives.  Most file accesses are still
   sequential.

4. There is a difference between interface and
   implementation. Although we speak of I/O being sequential, we do
   not necessarily mean that lseek() always has to start at the
   beginning of the file. Some of your wrote that to write a
   particular pixel on the graphics device, e.g. pixel (1000, 1000),
   you would have to read or write through all the pixels before that
   one starting at (0, 0), just to get there!  But this is not
   neccesarily true.  The lseek() function provides an interface to an
   application; the function is implemented differently depending on
   the actual device being used. For example, maybe a tape actually
   has to scan around to lseek(), but the driver for a disk device can
   translate the lseek() offset into the appropriate disk block and
   find it.
   
   The problem with using lseek() for bitmapped graphics is as
   follows: imagine you want to draw a diagonal line, and the pixels
   of the graphics device are layed out in order by row, e.g. row1,
   row2, etc.  But each pixel in the diagonal line is in a different
   row, i.e. no two pixels are adjacent.  So you would have to issue a
   sequence of calls as follows:
   
   lseek(pos1)
   write(pix1)
   lseek(pos2)
   write(pos2)
   ....
   
   This is bad, because it takes two function calls just to write one
   pixel. It is even worse because those calls are system calls, which
   means that there is extra overhead switching between the process
   doing the writing, and the kernel, on every pixel.
   
   One alternative is to use some form of direct addressing in your
   I/O.  Some of you also knew that you could map your device's
   hardware into virtual memory.  That is, you could access parts of
   the device just by writing to certain locations in memory.  Thus
   writing pixels is just like writing to memory.  Of course, this
   means that the VM system is doing lots of work under the hood that
   the program doesn't know about.  But you did not need to say any of
   this in your paper to get good grades.

   If you are curious, check out mmap (man mmap).

5. Also, get straight to the point -- avoid rehashing the question,
   we already know it.  carefully support and justify any conclusions you
   reach.