Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84; site hao.UUCP
Path: utzoo!linus!decvax!genrad!wjh12!harvard!seismo!hao!hull
From: hull@hao.UUCP (Howard Hull)
Newsgroups: net.jokes
Subject: Unix Joke - Slightly Technical
Message-ID: <1226@hao.UUCP>
Date: Mon, 22-Oct-84 10:00:29 EDT
Article-I.D.: hao.1226
Posted: Mon Oct 22 10:00:29 1984
Date-Received: Tue, 23-Oct-84 06:15:18 EDT
Distribution: net
Organization: High Altitude Obs./NCAR, Boulder CO
Lines: 45

A student, who had the previous year obtained some experience interfacing
various peripherals to an LSI-11/23 while working a summer job for the Physics
department, obtained a job this summer for the CSEE department doing similar
tasks on a PDP11-70 running UNIX.  His first assignment was explained to him
thus:
   "We're having trouble with our new large-screen bit-mapped graphics
    display on the 11-70, which is driven through a DMA interface.  Each
    user sends a job to the graphics daemon, and it puts them on a queue
    for the interface driver.  Since the graphics display only accepts data
    as consecutive bytes during the vertical sync interval, and the Unibus
    can be doing DMA with another device at that time, access to the graphics
    display is not always precisely as required by the interface.  We thus
    put in some code to monitor bus activity.  If the job can't run because
    the Unibus is too busy, it gets swapped out.  Currently the problem is
    that the swap space gets filled up with all these jobs because of the
    limited throughput, and the system panic traps and crashes."
"Well," the student thought, "I'll just write an assembly language driver
that can monitor the line frequency clock, grab the Unibus for a 1 millisec
interval at an appropriate time after each clock tick, and spit this stuff
to the DMA.  I won't have to look at any flags or anything, because I know
this is a synchronous process; it can't possibly come out wrong."
So the student wrote up the appropriate code, complete with the hardware
addresses for the graphics DMA, assembled it with the macro assembler,
and attempted a short test with the resultant executable.  Of course, he
got a segmentation violation.  He then found one of the wizards to get a
little advice.  The wizard told him "Oh, you can't do that with Unix, you
have to understand how your driver interfaces to the kernel in the OS.
Check /sys/source for the user c code.  I think its in s4; maybe malloc.c
or calloc.c will get you info on user calls to allocate memory.  Of course
then you should check out /sys/sys/os and look at malloc.c in there.  The
name is the same, but the code is different.  This applies to malloc.c in
/sys/sys/io as well.  Be sure and read /sys/sys/io/busmap.c for a good
explanation of how Unix allocates DMA io through the Unibus Map."  The student
staggered ruefully away.  A while later, the boss came by to see how he was
doing.  "How's everything?" the boss chirped cheerfully.  "Oh, ok I guess,"
replied the student.  "Do you know what you're supposed to do now?" asked the
boss.  "Well," replied the student, "When you're up to your OS in allocators,
it's hard to remember that the task was to empty /dev/swap!"
(-:(-:(-:(-:(-:(-:(-:(-:(-:(-:(-:(-:(-:(-:(-:(-:(-:(-:(-:(-:(-:(-:(-:(-:(-:(-:
:-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-)
 Smiles Left and Right...
In attempting to overcome an efficient foe, you are transformed...
						       Into you enemy's image.
Howard Hull
 	{ihnp4!stcvax | decvax!stcvax | seismo} !hao!hull