*BSD News Article 14298


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