Return to BSD News archive
Xref: sserve comp.os.386bsd.announce:12 comp.os.386bsd.development:245
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!agate!usenet
From: jmonroy@netcom.com (Jesus Monroy Jr)
Newsgroups: comp.os.386bsd.announce,comp.os.386bsd.development
Subject: QIC NEWS; vol. 1, no. 3
Followup-To: comp.os.386bsd.development
Date: 19 Mar 1993 16:31:20 -0800
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Lines: 435
Sender: cgd@agate.berkeley.edu
Approved: 386bsd-announce-request@agate.berkeley.edu
Message-ID: <1993Mar19.114125.9051@netcom.com>
NNTP-Posting-Host: agate.berkeley.edu
Status: RO
eleased
+----------------------------------------+
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.3
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".
Disclaimer:
"QIC" is a registered trademark of the
Quarter-Inch Cartridge Drive Standards, Inc. (QIC).
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 an editoral goddess of grammar corrections.
*=======================================*
| Tabloid contents |
*=======================================*
| <1>__ Implementation problems |
| <2>__ Design problems |
| <3>__ Backward compatibility problem |
| <4>__ Problem of the (un)Convention |
| <M>__ Meaningless dribble. |
| <F>__ FLAMES to the editor |
| <N>__ NEXT ISSUE |
*=======================================*
hint: search for "<?>__"
<1>__ Implementation Problems (from the software side).
NO Shared Libraries
-------------------
Oddly enough, I believe there is a shareable library,
but the documentation is not complete enough in a lot of cases.
Since the underlying structure for the I/O bus is different than
the traditional VME BUS, the documentation previously released
does not apply. In the long run, problems like this will
be handled by OOPS type implementations to the OS, but, until
then you must really hunt and peck.
Unsure About Library Calls
----------------------------
It may seem like another odd topic, but take the
rarely documented problem of writing to I/O ports incorrectly.
The problem is that some chips sets expect a latency time
between writes to multiplexed ports, like the EGA ports. What
may happen is this: If a writer does an "outw" (out single word)
when he/she should be doing a double "outb" (out single byte),
the port will jam. In the case of the EGA, since most of the
ports are read only, the writer will lose the context of the
situation and not be able to resolve it quickly.... It is a
really messy problem...
This code clip shows the right way and wrong way.
;; wrong way
outw dx, ax ;; write a word (16-bits) to a port
;; right way
outb dx, al ;; write the LSB (least significant byte)
xchg al,ah ;; exchange high for low
nop ;; wait settle time (about 2 clock cycles)
outb dx, al ;; write new LSB
Is OS Giving Me Priority?
-------------------------
What a question to ask! I wish I could answer this
question with some certainty, but there has not yet been a way to
get this information cleanly.
The problem arises when some hardware, which is being
ported, expects a real-time response. The QIC tape drive is one
such device. The specifications for use of the FDC in an "interrupt
mode" calls for a "Maximum Time Allowed for a Service" at 14us
for the data rate of 500kbps. This means that if the interrupt
for a DMA transfer or a "result phase" is not answered in the
allotted time, the FDC will mark it as an error. This is, of
course, important to the QIC tape drive since the FDC is
intermediate for all communications between it and the CPU.
<2>__ Design Problems.
The problems now become more general in nature. The
reason is the future.
Without getting too philosophical, I will state plainly
that many of you have seen the technology move, in gross
dimensions, to progressively smaller hardware implementations.
Obviously, as things get smaller and smaller, we will be asked to
do more with the hardware objects of the same size. It is only
reasonable.
So, how does this become a Design Problem?
It means we have to design the software before the
hardware gets to us.
How do we do this?
Tools of caliber and precision.
How do we know what tools we will need?
Lucidity provokes us with the contention that every possible
implementation cannot be foreseen. 64-bit or 128-bit data paths
provide the next logical choices. The 32-bit systems are the present
reality. We just have to plan a bit better.
I've gotten a bit too far out in left field.
"Let's cut to the chase". If you know about OOPS design,
like say, Smalltalk, then you know that we need solutions in that
realm.
You may be asking "Isn't C++ OOPs?".
NO, not really. It has a lot of neat OOPs-type ideas
working for it, but it tries to bind tightly to the original
"C" idea. It will just need to be re-examined,
especially by the mass of "C" programmers.
'NUF soapbox stuff.
<3>__ Backward Compatibility Problems.
SCHEMA, the idea--not the language. I won't let this get
too ugly; I will just say the word is related to SCHEME. Previous
OSs (Operating Systems), this one included, work on ideas that are
now dead... like core_memory, drum_memory, punch_tape, and 6-bit
codes. I don't want to get into detail on this, so if you have
any questions, please post them for general response.
The next related item is a perplexing one. It is that of
"not carrying the old bugs with you". It would seem that we would
like to get rid of bugs, but some old codes do not transport
well to new hardware. Examples of this are best visible when
you look at the TTY driver sets. Let's say a terminal does not follow
the VT100 "command set". You can see entries, such as this, that seem
to follow the hardware fix almost verbatim.
The last problem I will mention, in this regard, is that
of "garbage collection". This is an old paradox and is mentioned
again and again as a constant thorn. Here is an example of the
classic situation: Old code is being rewritten for a new driver,
but do you remove the old patches to hardware problems? And if
you do remove the patches, do you also remove the old errors codes
that went with it?
Can we get a handle on this problem? Yes, if the
documentation and "regression tests" reflect the old code SCHEMA
correctly... hmm... we just made a vicious circle.
<4>__ Problems of the (un)Convention.
Following tradition? Does this mean that I have to
follow bad ideas? And, what is a bad idea? I won't say any more
on this, except for the obvious.
Did the constructors of the original drivers give it
structure? Is it modular?
In a lot of cases, the code is not modular. This can be
seen in the way the I/O buffer variables migrate in and out
of the old drivers. This was a good idea then; it was a way to
cut down on overhead. However, when you do this, implicitly you
slow the system down. So, maybe, we need to get rid of this and
add modular structure.
Why do we want to add modularity?
With modularity, you explicitly get transportability.
If done right then, transportability, in theory, crosses hardware
boundaries.
Where can you get the most transportability?
In OOPs type design. The place I can describe this best is
inheritance. With inheritance, new hardware implementations
need only modify the section of code that pertains to it,
such as "xxprobe()" and/or a "xxprep()**".
At this point you might say "Well, that's great theory,
but that's not life!". Well, the QIC-40/80 now becomes the
best example. Here we have a device which attaches to a known
port and does not act as expected.
What do I do?
Rewrite and duplicate the FDC?
Forget that idea, from a purely overhead point of view
the prospectus to look for a standard. So for the QIC, then,
there is the QIC-117. Under observation, though, we can see
that the FDC interface does not follow FDC logic.
So, now what?
I alias the function in a virtual method through a
dynamic bind. Unfortunately, this methodology is not as
clean and clear as other languages. The bind is an explicit
method, not an implicit, like Smalltalk.
BTW, if "virtual method" and "dynamic bind" sound like
Greek, ask someone.
OK, now the rough part.
Identification with the familiar.
Whose form of code style blocking should I use?
If I am going to migrate to a new method of thinking, then
shouldn't my writing style reflect this? I have been talking a lot
about Smalltalk, so you might think I am an advocate of it. I am, but
not for Operating Systems.
In Smalltalk, the sections between the double quotes
are the comments. The sections between the "|" are local
temporary variables. The ":=" is an assignment symbol.
The call to the function is made as:
changeBits: theAddressOfTheBitYouWantToCha
HERE is a clip from Smalltalk:
------------------------------
changeBits: aPoint
"The select button has been pressed at aPoint in the
magnified pane. Reverse the bit under the cursor and
all bits the cursor moves over until the select button
is released."
| aChar locX locY newX newY |
locX := -1.
locY := -1.
[newX := Cursor offset x - bitPen clipX // scale.
newY := Cursor offset y - bitPen clipY // scale.
(newX = locX and: [newY = locY])
ifFalse: [
locX := newX.
locY := newY.
self setX: locX
Y: locY].
Terminal read == EndSelectFunction]
whileFalse: [self checkCursor]!
** xxprep is going to be for the FDC driver a new vital
function for preparing the FDC for commands.
<M>__ Meaningless Dribble.
"I hope you do continue sending me the money; you know,
it costs lots to look this cheap."
-Dolly Parton
-Tonight Show/03-05-1993
"Parallelism is the norm, purely sequential problem
solving is the anomalous restriction"
-Nicholas Carriero & David Gelernter
-How to Write Parallel Programs
-Chapter 1, p.1
"You hang out with some pretty amazing losers"
-Jeff Dehard
-Poet, Rock Mewzician
<F>__ FLAMES To The Editor
====================================================
to: jmonroy@netcom.com
from: "common net wisdom"
re: Subject: Re: Subject re: Subject: Re: Subject re: Subject: ...
> Before I tear some new *ssh#l%s, I would ask your opinion.
> ::
> How long has this continued BS of professed knowledge
> been going on with this group?
Which particular BS are you referring to. Remember, this is
Usenet... AKA the Net of a Million Lies. There is no entrance
exam, and nothing but the quality of ones posts differentiates
the fools from the folks with real understanding. Rest assured
that the people who are worth convincing can figure out which
are which without the need to flame.
Not that it doesn't feel good to flame a fool on occasion, it's
kind of like wrestling with a pig. The pig enjoys it, and you
both get dirty.
====================================================
VVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
With wisdom such as this, I sometimes wonder why I speak.
Thanks for your comments,
jmonroy@netcom.com
====================================================
Subject: no subject (file transmission)
Date: Fri, 12 Mar 93 8:23:09 CST
From: Al Amet <uncal@barney.tallgrass.com>
To: jmonroy@netcom.com
Subject: QIC NEWS
I thought I would inform you in case you didn't
know "QIC" is a registered trademark of the
Quarter-Inch Cartridge Drive Standards, Inc. (QIC).
Oh yea, they have a publication called QIC DATA NEWS.
---
--------------------------------------------------------------
Al Amet (Unc Al) Tallgrass Technologies
uncal@tallgrass.com 11100 West 82nd Street
Voice:(913)492-6002 Lenexa, KS 66214-3313
====================================================
VVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
Thank you AL,
I believe that the Supreme Court stated
that any words (or acronyms) that go into wide use
are no longer considered trademarks or copyrightable
(i.e., book titles and song titles are not copyrightable).
The phrase "Xerox copy" is also uncopyrightable or
cannot be legally defended as a trademark.
But, in the interest of fair play, and the
fact that without the good people at QIC and
Freeman Associates, I could not produce such dribble.
I will, in the future, acknowledge their trademark
and the distinction that they publish a newsletter
with a similar name to mine.
Thanks for your comments,
jmonroy@netcom.com
====================================================
From: nate@fubar.cs.montana.edu (Nate Williams)
Date: Fri, 12 Mar 1993 20:44:14 -0700
To: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: Re: Subject: Some Sample Projects for 386BSD
> NOTE to NATE or/and Jordan:
> You have my messages to you... If you feel that
> I did not communicate them effectively _or_ I sound like
> blithering fool _________ e-mail me.
Well, to be completely honest (no offense to you), sometimes the
'additional editorial' information you attach with your posts tends
to be quite distracting.
For example, statements like
> "If you cannot -in the long run- tell everyone what you
> have been doing, your doing has been worthless."
> -Erwin Schrodinger.
tend to put people off. This is a technical newsgroup, and most of the
readers are not interested in philosophical statements by some person
they have never heard of(or if they have heard of them, they really
don't care).
People are interested in results, not talk. But, as you ....
::
It may be in your personality to keep technical and philosophical
thoughts in the same vein, but speaking for myself (and others with
whom I've had conversations), it tends to make me lost track of what
you are saying.
::
[deleted]
::
Oh, one more thing. One of my PET PEEVES is not sticking with
standard coding styles. I understand that some people work
better with this coding style or that coding style, but your
fd.c driver was SO HACKED UP from the original that it's
impossible to tell what, if anything you've done with it.
1) The BSD copyright was removed. The original was, and still is
copyrighted by UCB, since Bill donated the code.
2) It's impossible to track changes you've made from the original
3) After reading lots of 386BSD code, you get used to the style that is
used, and your code stands out like a sore thumb, and a person has to
re-learn how to read it. Pain in the BUTT
4) I don't have a 132 column printer, or monitor. This code is going to
be distributed to thousands of people who also have limited resources.
I realize this isn't released code, but I think placing some of your
comments in a separate file would be more beneficial than placing long
documentaries at the beginning of the file.
Anyway, sorry for the long dissertation, but you did ask for comments.
====================================================
VVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
I wish half the people who write to me could be as honest
and clear about what they are saying.
Any further comments to Nate are between ourselves, but
I have seen some of his comments as helpful and, by the time most
of you read this, I will have already posted:
"Kindling Material .... send flames in early"
Thanks for your comments,
jmonroy@netcom.com
====================================================
<N>__ NEXT ISSUE
Dumb things not to DO.
Smart things you should consider.
___________________________________________________________________________
Jesus Monroy Jr jmonroy@netcom.com
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________