Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.unix.questions
Subject: Re: /dev/null: The final frontier
Message-ID: <5862@brl-smoke.ARPA>
Date: Fri, 15-May-87 16:36:18 EDT
Article-I.D.: brl-smok.5862
Posted: Fri May 15 16:36:18 1987
Date-Received: Sat, 16-May-87 17:30:47 EDT
References: <100@upas.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Distribution: world
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 15

In article <100@upas.UUCP> rcw@upas.UUCP (Robert White) writes:
>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?

It's hard to believe you're serious, but:
The device driver for /dev/null (traditionally bundled into the
/dev/mem driver) does nothing except return a file decriptor
upon open(), does nothing except liberate the file table entry
upon close(), returns a 0 byte count upon read(), and returns
a full byte count upon write().  The user's data is not necessarily
touched during the write().  There isn't any question of data
"going" anywhere; it's just bit patterns in memory and the system
can manipulate them as it sees fit so long as the documented rules
are obeyed.