Subject: QIC NEWS; vol. 1 no. 3
From: [email-masked] (Jesus Monroy Jr)
Date: Sat, 20 Mar 1993 17:07:02 GMT
Newsgroups: comp.os.coherent,comp.os.linux.announce,comp.os.mach,comp.os.minix,comp.os.xinu,comp.periphs,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.os.386bsd.developmet

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.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 the 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: [email-masked]
        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,
                                        [email-masked]
 
        ====================================================
        Subject: no subject (file transmission)
        Date: Fri, 12 Mar 93 8:23:09 CST
        From: Al Amet <[email-masked]>
 
        To: [email-masked]
        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
        [email-masked]                     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,
                                        [email-masked]
        ====================================================
        From: [email-masked] (Nate Williams)
        Date: Fri, 12 Mar 1993 20:44:14 -0700
        To: [email-masked] (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,
                                        [email-masked]
 
        ====================================================
 
  <N>__ NEXT ISSUE

        Dumb things not to DO.
        Smart things you should consider.

-- 
Send submissions for comp.os.linux.announce to: [email-masked]