rcw@upas.UUCP (Robert White) (05/14/87)
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
gwyn@brl-smoke.UUCP (05/15/87)
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.
warren@sniff.UUCP (05/16/87)
Where do all the bits go!? There has been much concern over this here at my workplace. Reason: It is thought that the bits pop out of the known universe. If this is true, we are loosing precious mass. This could result in an open (as opposed to a closed) universe. What a downer! Warren
jon@eps2.UUCP (05/16/87)
When you write to /dev/null, the kernel always gives you back the number of bytes you specified in the write as the return value. When you read from /dev/null, the kernel always gives you back 0 as the return value. On this Sun-3/160 running 3.2, the kernel doesn't check if the second argument is a valid address in the user's space. Jonathan Hue DuPont Design Technologies/Via Visuals leadsv!eps2!jon
mechjgh@tness1.UUCP (8753) (05/16/87)
In article <100@upas.UUCP>, rcw@upas.UUCP (Robert White) writes: > > this line == can of raid > 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? They go into a bit bucket. You mean your system administrator hasn't emptied it lately? :-)
jfh@killer.UUCP (John Haugh) (05/16/87)
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.
root@flattop.UUCP (Ron McDowell) (05/17/87)
In article <100@upas.UUCP>, rcw@upas.UUCP (Robert White) writes: > Where do the bytes go when moved or copied to /dev/null? I am sure you've noticed the dust in the back of the computer... ;-) (Seriously, this is a good question, and one I would like to see an answer for also!) -- Ron McDowell @ Programming Consultants +1 512 826-8627 354 Timberlane Drive rcm@flattop.UUCP San Antonio, Texas 78218-4248 {akgua|gatech}!petro!flattop!rcm "It's MY system...I'll say anything I want!"
warren@pluto.UUCP (Warren Burstein) (05/17/87)
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? 1+2) The bytes written to /dev/null go the same place as bits shifted out of the accumulator. Your Field Engineer has to periodically come in and remove them. Unfortunately there is no indication when the recepticle is full. It gets full faster if you don't discard equal numbers of 1's and 0's. VERY IMPORTANT: Do not try to remove the bits yourself! 3) /dev/null is a special case of memory. Think about it. cr--r----- 1 sys 3, 0 Jul 17 1984 /dev/mem cr--r----- 1 sys 3, 1 Jul 17 1984 /dev/kmem crw-rw-rw- 1 root 3, 2 May 16 22:17 null -- /|/~\~~\ The entire world Warren Burstein |__/__/_/ is a very narrow carrot. | But the farmer philabs!tg!pluto!warren / is not afraid at all. Why doesn't life come with subtitles?
levy@ttrdc.UUCP (Daniel R. Levy) (05/17/87)
In article <100@upas.UUCP>, rcw@upas.UUCP (Robert White) writes: < 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? The UNIX system implementation of /dev/null is such that write(fd_connected_to_/dev/null,bufferpointer,length) /* unsigned length, by definition >= 0 */ will return length without bothering to access the data at bufferpointer, or (sometimes? always?) even bothering to check if the array of length length starting at bufferpointer is within a readable part of the process' address space. < Robert White < Graphics Information, Inc. < UUCP: seismo!hao!scicom!qetzal!rcw -- |------------dan levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, | an engihacker @ | vax135}!ttrdc!ttrda!levy | at&t computer systems division | Disclaimer: try datclaimer. |--------skokie, illinois--------|
ado@elsie.UUCP (05/18/87)
I suppose this is already in Version N. . .but what I have a use for every month or so is "/dev/full"--so that I can do a dumb timing test this way: dd if=/dev/full of=/dev/rmt8 bs=20b While /dev/null always says "I successfully wrote as many bytes as you asked me to", /dev/full would always say "I successfully read as many bytes as you asked me to." -- UNIX is a registered trademark of AT&T. -- UUCP: ..seismo!elsie!ado ARPA: elsie!ado@seismo.CSS.GOV Elsie and Ado are trademarks of Borden, Inc. and Ampex.
art@acc.arpa (05/21/87)
Now SERIOUSLY :-) hasn't ANYONE heard of "The Law of Conservation of Bits"? This law states that bits can't be created or destroyed, only transformed between 0 state and 1 state. The number of bits (and anti-bits) created in the "Big Bang" is therefore constant. Where do you think that all those bits you write to the null device came from? They are extracted from the ETHER and that is precisely where they end up when written to the null device or written over in a machine register. Some of the newer Binary Unified Gauge System (BUGS) theories predict that a bit with no external perturbations may spontaneously change its state. It is left as an exercise to the reader as to what happens when a bit and its counterpart anti-bit come in contact. (-: Art@ACC.ARPA :-) ------
berryman@megatest.UUCP (05/22/87)
in article <100@upas.UUCP>, rcw@upas.UUCP (Robert White) says: > > > 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 Here's the honest to god truth from someone who spent years optimizing the driver for /dev/null: 1. The bytes are sorted by age and are kept around for use by other processes. Integers are stored in network order and one must be careful to use ntohs and ntohl before using. 2. The machine stores the data - no heat is released. (see 1). 3. Writes to /dev/null do not occur immediatly but are buffered in a special buffer cache maintained specifically for /dev/null. Writes to /dev/null are processed in order of decreasing pid*uid/log(averun). Common program errors may occur because of this ordering scheme. Reads from /dev/null are non-blocking and asynchronous so the programmer may never be sure when the read is completed. Hope this helps you sleep better. Ed Blackmond Lieutenant Kernel Hacker Megatest Corporation 880 Fox Lane San Jose, CA 95035 {sun, amd, fortune, dlb}!megatest!eb Disclaimer -- The above opinions are those of the author and should be considered the gospel truth.
jpn@teddy.UUCP (John P. Nelson) (05/22/87)
While it is true that bytes that are written to /dev/null go into the bit bucket, it is not true that servicemen need to empty the bit bucket periodically as long as the user community helps out a bit. The bitbucket is drawn upon by programs which use the "rand" and "random" function interfaces. Each call draws 16 or 32 bits out of the bit bucket. There is a REASON why games like "rogue" and "backgammon" come with unix: Playing them helps to empty out the bit bucket. Make sure you play at least one hour of games a day, or the bit bucket may overflow (this can cause your computer to blow up, so be careful out there!)
brandon@tdi2.UUCP (Brandon Allbery) (05/23/87)
Quoted from <7416@elsie.UUCP> ["Re: /dev/null: The final frontier"], by ado@elsie.UUCP (Arthur David Olson)... +--------------- | I suppose this is already in Version N. . .but what I have a use for every | month or so is "/dev/full"--so that I can do a dumb timing test this way: | | dd if=/dev/full of=/dev/rmt8 bs=20b | | While /dev/null always says "I successfully wrote as many bytes as you asked | me to", /dev/full would always say "I successfully read as many bytes as you | asked me to." +--------------- Anyone remember the pseudodevice in CP/M that returned 40 (I think) nulls on a read? ++Brando -- Brandon S. Allbery UUCP: cbatt!cwruecmp!ncoast!tdi2!brandon Tridelta Industries, Inc. CSNET: ncoast!allbery@Case 7350 Corporate Blvd. INTERNET: ncoast!allbery%Case.CSNET@relay.CS.NET Mentor, Ohio 44060 PHONE: +1 216 255 1080 (home +1 216 974 9210)
roy@phri.UUCP (Roy Smith) (05/23/87)
Up until a year or so ago, bytes written to /dev/null were
automatically posted to net.flame; now I think they get split evenly
between soc.singles and comp.unix.wizards.
--
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016zben@umd5.umd.edu (Ben Cranston) (05/26/87)
In article <7488@brl-adm.ARPA> art@acc.arpa writes: > Where do you think that all those bits you write to the null device came > from? They are extracted from the ETHER and that is precisely where they > end up when written to the null device or written over in a machine register. Yes, many people do not know this, but most modern computers have Ethernet interfaces, which not only communicate with other computers, but also have a side-effect of drawing new bits from the Ether. Thus newer computers do not need to be loaded with zero-bits each weekend (see below). > Some of the newer Binary Unified Gauge System (BUGS) theories predict that > a bit with no external perturbations may spontaneously change its state. Unfortunately experiments with 6.023 x 10^23 molecules of water in a baggie in my basement conclusively prove that the decay of one-bits to zero-bits proceeds so slowly that bit conversion is not a feasable way to recycle bits. It has been proposed that the bit-bucket hardware of most computers be enhanced to sort the zero-bits and one-bits into separate buckets. If this be done, these buckets can be the source for new bits needed by the major bit-consuming instructions of the computer, namely the shifting instructions (note rotate instructions do not need a source of new bits). Careful modeling and experimentation with actual computer programs shows that "logical" shifts (those that fill with zero-bits) are much more used than "arithmetic" shifts (those that fill with zero or one bits depending on the sign of the quantity). Thus computers are always running out of zero-bits, and always have an excess of one-bits that must be removed each weekend by customer engineering. Those of us who are environmentally active often wonder just what happens to those one-bits. One "urban myth" is that they are shipped to Israel, where not only do the bits go from right to left, but one-bits and zero- bits are interchanged (i.e. a zero sign bit means negative, etc). My colleagues and I suspect that IBM has been collecting them for the past 20 years, and dumped them one dark night on a certain garbage barge, which has been wandering the coast like a Flying Dutchman ever since... OK, enough time wasted on this, M*A*S*H is on... See ya! ("It's just a JOKE!") -- Copyright 1987 Ben Cranston (you may redistribute ONLY if your recipients can). umd5.UUCP <= {seismo!mimsy,ihnp4!rlgvax}!cvl!umd5!zben zben @ umd2.UMD.EDU Kingdom of Merryland UniSys 1100/92 umd2.BITNET "via HASP with RSCS"
robert@hslrswi.UUCP (05/27/87)
In article <100@upas.UUCP> rcw@upas.UUCP (Robert White) writes: >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? > >Robert White The answer may just be yes. Seriously. In an article entitled "Complexity and Transcomputability" in the book "The Encyclopedia of Ignorance" (Pergamon Press, 1977), Hans J. Bremermann (apparently then Professor of Mathematics and Biophysics at UCB) writes : Another kind of limitation to computation may be thermodynamic. R. Landauer (1961) has pointed out that when in the course of computation information is discarded, entropy is generated which must be dissipated as heat. How much information must be discarded when computations are carried out ? Initially this question was not well understood. Recently Bennett (1973) has shown that any computation can be carried out essentially in a logically reversible way which implies that it can be done with little or no entropy generation (cf. also Landauer, 1976). In Landauer and Woo (1973) both thermodynamic and quantum limitations are discussed and an extensive bibliography is given. There are many open questions. Bennett, C. H. (1973) - "Logical reversibility of computation", IBM J. Res. Devel., 17, 525-532. Landauer, R. (1961) - "Irreversibility and heat generation in the computing process" - IBM J. Res. Devel., 5, 183-191. Landauer, R. (1976) - "Fundamental limitations in the computational process" - Bericht Bunsengesellschaft Physikal. Chem 80" Landauer, R. and Woo, J. W. F. (1973) - "Cooperative phenomena in data processing" - Synergetics, edited by H. Haken and B. G. Teubner, Stuttgart. I doubt whether the bit bucket will ever fill up, but writing to /dev/null may eventually cause your machine to overheat. Cheers, - Robert. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ J. Robert Ward, ___________ Hasler AG, Belpstrasse 23, CH-3000 Berne 14, Switzerland | _ | | _| |_ | Tel.: +41 31 632319 | |_ _| | X.400: robert@hslrswi.hasler | |_| | Bitnet: robert%hslrswi.UUCP@cernvax.BITNET |_________| Uucp: ... {seismo,ukc, ... }!mcvax!cernvax!hslrswi!robert ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gdelong@cvbnet.UUCP (Gary Delong) (05/28/87)
In article <1705@umd5.umd.edu>, zben@umd5.umd.edu (Ben Cranston) writes: > In article <7488@brl-adm.ARPA> art@acc.arpa writes: > > > Where do you think that all those bits you write to the null device came > > from? They are extracted from the ETHER and that is precisely where they > > end up when written to the null device or written over in a machine register. > > Some of the newer Binary Unified Gauge System (BUGS) theories predict that > > a bit with no external perturbations may spontaneously change its state. > > Unfortunately experiments with 6.023 x 10^23 molecules of water in a > baggie in my basement conclusively prove that the decay of one-bits to > zero-bits proceeds so slowly that bit conversion is not a feasable way > to recycle bits. > > Those of us who are environmentally active often wonder just what happens > to those one-bits. One "urban myth" is that they are shipped to Israel, > where not only do the bits go from right to left, but one-bits and zero- > bits are interchanged (i.e. a zero sign bit means negative, etc). > > My colleagues and I suspect that IBM has been collecting them for the > past 20 years, and dumped them one dark night on a certain garbage barge, > which has been wandering the coast like a Flying Dutchman ever since... > Ok, I guess it's time a hardware type let all you software jocks in on the facts. There is no such thing as a bit-bucket. You should all read some the excellent articles in comp.hw.design on the issue. One of the first laws of computer hardware design is the law of conservation of bits. Your system when you bought came with some number of bits included, that is also true of mass storage devices such as disk and tape. If you are running a 4MByte system with 80MByte disk drive you have 84MB of bits (plus some spare bits which are "purchased" or returned by the OS from time to time as required to/from the control STORE ). These presupplied bits are normally supplied in 50/50 distribution between 1s and 0s (some applications require other ratios and are either compensated for by the hardware manufacturer or by the software manufacturer on the disk or tape the software comes on). The real job of the CPU is to move these bits around to represnt the data you want, some are stored in the keyboard to be sent to the system when you press a key, the CPU resupplies devices such as this on a time slice basis. This is why many times you will find strange problems with your system when your disk is almost full as the remaining disk area may be left all 1's or 0's depending upon your usage. No, networking does not move bits from system to system, those misterious particles called bauds tell your CPU how to rearange the bits within your system. I hope this settles this once and for all. PS: The only bit mines left in the world are in South Africa, so you better hope something happens so to resolve the problems there before our national bit reserves are depleted. PPS: No one seems to really understand what happens to the bauds once they have done their job, or even where they come from. -- _____ / \ / Opinions?? Gary A. Delong, N1BIP | \ / I'm not allowed linus!raybed2!cvbnet!gdelong \____\/ to have those. (617) 275-1800 x5232
greg@xios.XIOS.UUCP (Greg Franks) (05/29/87)
In article <1705@umd5.umd.edu> zben@umd5.umd.edu.UUCP (Ben Cranston) writes: >It has been proposed that the bit-bucket hardware of most computers be >enhanced to sort the zero-bits and one-bits into separate buckets. If >this be done, these buckets can be the source for new bits needed by the >major bit-consuming instructions of the computer, namely the shifting >instructions (note rotate instructions do not need a source of new bits). Au contraire - Rotate instructions can be both a source and a sink of bits. The ROR and ROL instructions of the MC680*0 machines use the carry flag as a sink and a source of excess bits. (Note that these micro processors also have a ROXL and ROXR instuctions for multi-word (whatever) rotates). The excess bits (or needed bits) are converted to (or from) energy, just like mass. In fact, the laws of thermodynamics even apply! Quality energy (electricity) is needed to create a bit. However, you only get heat back when you destroy a bit! Hence the need for both cooling and a power supply. I believe the great computer scientists, Alfred Epstein, has come up with some sort of relativity theorem to the effect that E = mc ** 2, where E == energy, m == mips and c == the carry flag. -- Greg Franks (613) 725-5411 "Vermont ain't flat" {net-land}!utzoo!dciem!nrcaer!xios!greg (Other paths will undoubtably work too - your mileage will vary)
ksand@mapper.UUCP (Kent Sandvik - the minor super user) (05/29/87)
In article <608@hslrswi.UUCP> robert@hslrswi.UUCP (J. Robert Ward) writes: >>Where do the bytes go when moved or copied to /dev/null? >>Does the machine dissipate the data as heat? >>Robert White >The answer may just be yes. > > >I doubt whether the bit bucket will ever fill up, but writing to >/dev/null may eventually cause your machine to overheat. Hmm, thats easy to implement... while true do cat /etc/passwd >/dev/null done ...I wonder why it's getting so warm in the computer room just now? Kent Sandvik -- ADDRESS: Vallgatan 7, 171 91 Solna Sweden | Swedish Advertisement !!!!! PHONE: +46 8 - 55 16 39 job, - 733 32 35 home | PRENUMERERA P]: ARPA: enea!mapper!ksand@seismo.arpa | enea!sems!bitbucket m-listan UUCP: ksand@mapper.UUCP | "Ett m}ste f|r alla gurus"-zine
terryl@tekcrl.UUCP (06/04/87)
In article <311@xios.XIOS.UUCP> greg@sdn.UUCP (Greg Franks) writes: >In article <1705@umd5.umd.edu> zben@umd5.umd.edu.UUCP (Ben Cranston) writes: >>It has been proposed that the bit-bucket hardware of most computers be >>enhanced to sort the zero-bits and one-bits into separate buckets. If >>this be done, these buckets can be the source for new bits needed by the >>major bit-consuming instructions of the computer, namely the shifting >>instructions (note rotate instructions do not need a source of new bits). > >Au contraire - Rotate instructions can be both a source and a sink of >bits. The ROR and ROL instructions of the MC680*0 machines use the >carry flag as a sink and a source of excess bits. (Note that these >micro processors also have a ROXL and ROXR instuctions for multi-word >(whatever) rotates). Double au contraire (i.e. you're wrong, Bucko). I quote from the M68000 16/32-bit Microprocessor Manual (Fourth edition): "For ROL, the operand is rotated left; the number of positions shifted is the shift count. Bits shifted out of the high order bit go to both the carry bit and back into the low order bit. The extend bit is not is not modified or used." So rotates use the carry bit as a sink, but not as a source. Perhaps you were thinking of the ROX[L,R] instructions which do use the extend bit as both a sink and a source???? Boy How I Hate Inews !!