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