Return to BSD News archive
Xref: sserve comp.os.os2.programmer:10668 comp.os.coherent:8811 comp.os.linux.announce:491 comp.os.mach:2692 comp.os.minix:21778 comp.periphs:3450 comp.unix.bsd:11792 comp.unix.pc-clone.32bit:2270 Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!usc!rpi!batcomputer!db.TC.Cornell.EDU!mdw From: jmonroy@netcom.com (Jesus Monroy Jr) Newsgroups: comp.os.os2.programmer,comp.os.coherent,comp.os.linux.announce,comp.os.mach,comp.os.minix,comp.periphs,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.os.386bsd.developmet Subject: QIC NEWS vol.1 no.3 Date: 10 Apr 1993 15:48:07 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Lines: 531 Approved: linux-announce@tc.cornell.edu (Matt Welsh) Message-ID: <1q6q7n$ccv@fitz.TC.Cornell.EDU> NNTP-Posting-Host: db.tc.cornell.edu Keywords: QIC News tape driver Originator: mdw@db.TC.Cornell.EDU Released +----------------------------------------+ QQQQQQ II CCCCCC QQ QQ II CC N E W S QQ QQ II CC QQ QQ II CC for 386bsd QQQQQQ II CCCCCC Vol.1 no.4 QQ (r) +----------------------------------------+ News about QIC-40/80 From the desk of the quasi-editor-in-chief: "Just because I am numbering these things don't get the idea that I am going to do any more of these". "QIC" is a registered trademark of the Quarter-Inch Cartridge Drive Standards, Inc. (QIC). UNIX is a trademark of USL, a division of Novell (last I heard). This publication is not affiliated with "QIC" or "QIC DATA NEWS". All comments, issues, and errors are only attributable to the quasi-editor-in-chief. Thanks: Will Crawford, Wolfhound Computer Service, for the editorial critique and his comments on software design. Jennifer Gordon for being helpful in grammar corrections. *=======================================* | Tabloid contents | *=======================================* | <1>__ Dumb things not to DO. | | <2>__ Smart things ... | | <3>__ Designing from other points. | | <4>__ Another OS joins the effort. | | <M>__ Meaningless dribble. | | <F>__ FLAMES to the editor | | <N>__ NEXT ISSUE | *=======================================* hint: search for "<?>__" <1>__ Dumb things not to DO. While (1) --------- I will give out heat any time I see this one. Anytime you see this used, the programmer was either lazy or stupid. What does it mean? Look at it again, it means "do this forever". How long is forever? In this case, it is when you unplug the machine. Using sleep() vs. timeout() --------------------------- Sleep is what I need, but I think I will just finish these sections first. I wonder where this Idea came from. No doubt I will probably hear from comp.society.folklore on this one. In any case, lets put this one to bed; Maybe I should goto bed,, NAH. OK, OK, this function sleep() has been around from sometime and is a good way to do something really dumb. Let's see where could I use sleep(), maybe for a high priority device driver, like FDDI. NO, that doesn't sound like a really neat thing(FDDI, that is). How about in a keyboard driver? Sure, the user is usually half asleep anyway. OK, we found a home for this guy. Now, where would I put it? I got it! Let's call sleep() when the user is not using the keyboard. Sure, that way when he needs it, it's not there! Hmm.. let's continue, anyway. Sleep() literally halts a process dead cold and it does not continue until your time is up. Timeout() on the other hand can be used two ways. It can call a time out routine, like for maybe when something takes too long. Or, it can be called to start a separate and different routine. If you really get creative you can even call yourself, like I do in the fdc driver. Anything else rotten about sleep()? Yes, besides the program staying resident in memory, it also holds stack space in multipule areas. All this slows the total system response and performance. Hhgmm, let's go on! spl[xxx]() usage ---------------- It is real easy to be excessive with this. If you look below at "kernel stack de-loading.", you will see a real life example of bad spl[xxx] usage. This cut of code is in your source tree. Look at it. It is in /sys/i386/isa. It is called fd.c. It runs your floppy drive. And you thought life sucked. Why is this a major deal? spl is an acronym for Set Processpr Level (see Dr Dobbs March 1992). It does, when requested, give you the highest priority to do your service, whatever it is. You alone are the sole inheritor of time. You can now control and kill the system at will. Hmm... sounds like a great idea for virus. using "-1" as a buffer flag --------------------------- Somewhere in my ramblings I mentioned still being stuck in the dark ages. OK, Ok, I really said 6-bit machines. Believe this, I can today still find programers of six-bit machines. Where are they?, you ask. Doing Algol, Forth, and Smalltalk. They got bored with the dumb 6-bit machines and went on with life, maybe we should too. Why is "-1" such a big deal? Using it cuts down your buffer size by a power of two. They way it works is this: To store a negative number we have to store the "-" sign, somewhere. So, we store it in the high bit of a number. Here is an example: ---------------32 bit number----------- binary -----> 1000 0000 0000 0000 0000 0000 0000 0001 decimal -----> -1 binary -----> 1000 0000 0000 0000 0000 0000 0000 0001 ^ | + This digit store the negative sign. OK, 2 to the 31st power is 2,147,483,648, and 2 to the 32st power is 4,297,967,296. The loss is a power of 2. variable->maynotbewhatIwant --------------------------- This, like all great ideas, is one of the best and worst ideas ever invented. We see these a lot in new code. They make great holiday gifts and are fun to play with too. What makes this such a great idea is the ease with which one can change things. Imagine, you can with one operation, point to anything in memory; Anything, Doesn't Matter. Either protected or not, you then do anything you want. You can add, delete, overwrite, poke, and probe. All with just one operation to start you out. Hmm... sounds like another great idea for virus. That is the least of the dangers. The real problem comes about when you really want to do something. So you start out with this great idea, but it does not work, or worst yet it *seems* to work. So as it works out, pointing to a wrong section in memory is now as easy as 10-minute oil job. You think I'm silly with all this talk, right? Well, call Pure Software. They survive on a product that does nothing else but debug memory problems in UNIX. Their phone number is (408)720-1600. Sorry their product does not work with 386bsd. *(variabl[]->obfuscated()) ------------------------- Quick, What am I pointing to? Answer next issue. The winner gets a one year free subscription to QIC NEWS. <2>__ Smart things you should consider. array[100][100][100][100][100]; ------------------------------- How do you think about something like this? We only have three dimensions in real life. UP/DOWN, LEFT/RIGHT & FORWARD/BACKWARD. Well, get rid of that idea. It is the wrong way to understand this. I will give you an example, that maybe, can make it understandable. You live on a street with a name that is one hundred letters long. It is in a county with one of a hundred cities. The county is in a state with one hundred counties. The state is in a country with one hundred states. It all resides on a planet with one hundred countries. Look back now and you will see I used the words ONE and HUNDRED five times. In the array I made it, with five dimensions. What is the advantage? Any street, on the planet of our example, can be found within 1/10th of a second on any machine with the memory to hold our answer. The array is 10 Gigabytes in size, approximately. variable++; ----------- Funny enough most programmers are quite unaware that the machine instruction related to this operation is available on just about all modern processors. Along with this, it is among the fastest available instructions. For the i386, it uses only 2 clock cycles when in a register and 6 when accessing memory. This makes this, one of the most attractive ideas available. What is a good way to use this? See the next issue of QIC NEWS for this item, in the article Zero _or_ minimum flags and/or switches. abstract_table[my_name[your_addr[his_ss_no[what_I_want]]]] ---------------------------------------------------------- This idea is popular among the Data Base people, they call it a hash table. It is used in the BSD OSs, but it is not a real easy idea to deal with. It is not completely straight forward. So, I will try to explain it step by step. First there is the abstract table. What is in it? It does not matter for now because you are really just trying to access it through an index. OK? Next, the index is found by a search through an array of my name. Hmm.. What this gives use is a letter, maybe, a letter in may name. OK. Which letter in my name? The letter that is wanted is a number in your address, which is an array of digits. The digit we choose will be found as an index from his social security number. BUT, Which number in his SS# do we want? Ahh... look up at the first line. It is the number what_I_want kernel stack de-loading. ------------------------ This is best shown by a bad example. fdstrategy() { :[deleted}; splbio(); /* get kernel priority */ decide_something(); fdstart(); splx(); /* return priority to kernel */ } fdstart() { :[deleted]: Do_something(); do_reset(); } do_reset() { :[deleted]: more_stuff(); issue_command(); } issue_command() { :[deleted]: getting_boring(); /* ? */ outb(addr, cmd); /* cause an interrupt when done. */ } What can happen, which is hard to prove without testing hardware, is that by the time you have rolled back through the stack, the interrupt you wanted may have already happen. Especially, if you already had previously done a reset. OK, maybe the compiler was smart and caught this by optimizing the stack return to 2 or 3 instructions, but not likely. <3>__ Designing from other points. What follows was a message I got from Europe I considered it of value some I am including it in this issue. mail ah@alvman.RoBIN.de Subject: I like Your approach .... :: [deleted} :: I know what I'm talking about. When I was working at the Technical University of Darmstadt - Department of Statics - there were many guys who developed some real good stuff but it was almost impossible to maintain the source code. As system-manager on PDP-11 and later uVAX I realized that the following rules will produce optimal programs: 1. Put your algorithm in good structured routines 2. Write some documentation on the variables used, the algorithm and provide a flowchart. 3. Add comments at large to your source code. 4. Don't use implicit type declarations. Declare every type explicit! 5. Time invested in structuring and working on existing code is a good investment. You save it later! It's really no big deal, but it helps a lot. I know of (FORTRAN-) source where about 70 % of the code was unused due to extensively used goto statements. Why do I write all this? Well, first I liked your approach on the subject. Second I would like to see some guidelines for all those who contribute to the development of 386bsd. Most of them just have no idea. Third I'm fed up with the existing fd-driver. I'll write to R. Grimes today. Fell free to forward any of my proposals. <4>__ Another OS joins the effort mail hoppie@kub.nl Subject: QIC drives and OS/2 In the OS/2 community there's some concern about the ugly or non-existent support for the cheap CMS Jumbo drives that use the QIC40/80 protocol. ::[deleted:: In the sad case that you are still "investigating" instead of programming, maybe be OS/2 weirdos can join in a bit... :-) I 'til now understood that QIC is about bits and patterns on tape, and that the way of misusing the floppy controller might be typically CMS (at least, they themselves say it is a proprietary way of accessing the tape and will not give any details on it). Am I right? Can you give me or point me to additional information? At first, we're looking for some kind of feasibility study to estimate the amount of hard work a QIC* driver for OS/2 would cost. After all, commercial (and rotten) software is available for $100. The improvement we would obtain should be weighed against the potential five manyears of work :-) <M>__ Meaningless dribble. calibration accuracy - Calibration Accuracy is the limit of error in the finite degree to which a device can be calibrated (influenced by sensitivity, resolution, and repeatability of the device itself and the calibrating equipment). "The unknown is always there. Where do you stop?" -The Amazing World of Kreskin -Part 1, p.13 "The whole thing is to find a way to make the machine disappear; that is goal of the interface designer in life, period, to make everything disappear but the data you're delivering." -David Troub; Educational Warrior -Mar. 10, 1993 @ SVNET Meeting "Man has no Heaven or Hell, to put me in" -Missionary;3-29-93 -Bobbie Lute <F>__ FLAMES to the editor ==================================================== mail khk@raster.Kodak.COM Re: Subject: Re: Subject: Re: Subject: Re: QIC NEWS; vol.1 no.2 > I am trying to let the communities (386,linux,mach) know > we are working in a joint effort. > I'm happy that somebody has taken a more engineering like approach to the QIC-117 driver. If i had more time, that's the way i would have gone. But right now it is only important for me to get the tape drive some how to work, and that's the reason i patch Dave's driver, even if i don't know exactly what i'm doing :-). ==================================================== VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV Even I get tired of reading all the negative cr*p. Thanks for your comments jmonroy@netcom.com ==================================================== mail IMONTANA@CCIT.ARIZONA.EDU Re: Subject: QIC NEWS >> Why in god's name did you put the QIC NEWS onto >> the COHERENT forum? People pay for these connections, >> and drivel is not worth the cost :) >> Please refrain from sending v2 or v3 if such exist. ==================================================== VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV Sometimes I wonder why I cross post. BTW, haven't got to vol.2, yet. Thanks for your comments jmonroy@netcom.com ==================================================== mail sdo@cs.purdue.edu RE: Subject: Re: QIC NEWS; vol. 1 no. 3 >> Mr. Monroy, >> >> While I'm sure that your QIC postings are very >> informative, I ask that you stop cross posting >> them to comp.os.xinu. That news group is for >> research discussion relating to the operating >> system Xinu, so this information is not directly >> useful to our readers. >> >> No harm done, but please don't do it anymore. >> ==================================================== VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV QIC NEWS no longer gets posted to comp.os.xinu. Thanks for your comments jmonroy@netcom.com ==================================================== From: deraadt@fsa.ca (Theo de Raadt) Subject: Re: QIC NEWS; vol. 1 no. 3 Organization: little lizard city Date: Wed, 31 Mar 1993 22:38:00 GMT In article <1993Mar21.002818.7474@tc.cornell.edu> avg@rodan.uu.net (Vadim Antonov) writes: In article <1993Mar20.170702.29860@tc.cornell.edu> jmonroy@netcom.com (Jesus Monroy Jr) writes: >... > News about QIC-40/80 >... Those who can, do. Those who can't, write. Sorry, can't resist. --vadim Bravo. Been meaning to make a few statements myself, but I guess I've been beat. -- This space not left unintentionally unblank. deraadt@fsa.ca ==================================================== VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV This space intentionally filled. Thanks for your comments jmonroy@netcom.com ==================================================== <N>__ NEXT ISSUE The answer to what this means: *(variabl[]->obfuscated()) Things to come. -- Send submissions for comp.os.linux.announce to: linux-announce@tc.cornell.edu