Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!rutgers!ames!ptsfa!hoptoad!academ!killer!jfh
From: jfh@killer.UUCP (John Haugh)
Newsgroups: comp.unix.questions
Subject: Re: /dev/null: The final frontier
Message-ID: <894@killer.UUCP>
Date: Sat, 16-May-87 14:57:47 EDT
Article-I.D.: killer.894
Posted: Sat May 16 14:57:47 1987
Date-Received: Sat, 23-May-87 10:30:36 EDT
References: <100@upas.UUCP>
Organization: The Unix(tm) Connection, Dallas, Texas
Lines: 59
Summary: The most difficult device driver in the entire system ...

In article <100@upas.UUCP>, rcw@upas.UUCP (Robert White) writes:
> 
> this line == can of raid
> 
> Some of these questions may be trivial. I've lost sleep over them:
> 
> Where do the bytes go when moved or copied to /dev/null?
> Does the machine dissipate the data as heat?
> How does a null device driver work?
> 
> Robert White
> Graphics Information, Inc.
> UUCP: seismo!hao!scicom!qetzal!rcw

Well Robert - as a long time Unix guru, let me tell you that the last time
I ported Unix it took 3 or 4 days for the disk and tty drivers, but 6 _weeks_
to port the driver that handles /dev/null.

The reasons for this are simple.  Diffent cpu's and machines have different
ways of disposing of the bytes written to /dev/null, and depending on how
you implement the driver, you may wind up violating certain requirements,
such as reads from /dev/null always return end-of-file.

/Dev/null is easiest to implement on systems with virtual memory.  Since the
memory isn't real, the bytes aren't either!  Just save enough of them up
until you have an entire page, and unmap the page.  Simple as that.  Of
course, if you want to improve response time, you can unmap partial pages
that aren't completely full of /dev/null stuff, but that is wasteful.

Physical memory is the hardest to handle.  My favorite way is to swap the
process onto disk, removing the memory segment that contained the data for
/dev/null.  This can be sped up by coping the data segment to a new location
and zeroing out the old data segment thereby destroying the old bytes.  It
is important that you ZERO the data segment since otherwise the bytes will
still be there.

Back in pre-version 7 days, the bytes were dissapated as heat.  The device
driver repeatedly read the byte until it vanished and reappeared as a zero
byte.  This was not hard for the old machines that had alot of hot air anyway.
But the newer machines with liquid cooling never got hot enough to wear down
a byte, so they simulated the wear by zeroing bytes and what not.  The 1st
law of thermodynamics tells us that the same amount of work is needed to
zero a byte as to wear it down to zero, so the effects are exactly the same.
You might think that virtual memory violates this law, but in fact, on the
page table reference is subject to the 1st law.  And since we make certain
to zero that entry, the law isn't broken.

I hope that this has completely brought you up to date on /dev/null.
However, this document contains information that is a trade secret of
AT&T Bell Labs.  You are not allowed to repeat it to anyone, and merely
have read it requires you to immediately send $25,000 to Western Electric
for a Version 6 source license for the machine of their choice.  Good Luck.

- John.		(Freddy the Freeloader, Space Tripping again)

Disclaimer -
	The information contained herein was determined under grant from
	the DOD DARPA project at a cost of $1,650,000.  It is therefore,
	part of the public domain.  Have fun guys.