[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
6.033 one-pager 2 notes
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.