Re: [PARPORT] Re: Attention anyone using the pt driver

From: Russel Ingram (
Date: Fri Jun 15 2001 - 01:53:23 EDT

  • Next message: J. Scott Berg: "Re: [PARPORT] Re: Attention anyone using the pt driver"

    On Fri, 15 Jun 2001, J. Scott Berg wrote:

    > On Thu, 14 Jun 2001, Russel Ingram wrote:
    > > On Thu, 14 Jun 2001, Russel Ingram wrote:
    > >
    > > > I have added some extra functionality to the pt driver and am looking for
    > > > people to test it. The attached patch will add the following magnetic
    > > > tape ops to the driver:
    > > >
    > > > MTRETEN -- retention the tape
    > > > MTLOAD -- load the tape
    > > > MTUNLOAD -- unload the tape
    > > > MTERASE -- erase the tape
    > > > MTWEOF -- write end of file marker
    > Ah, MTWEOF. I messed with this a while back and kept intending to get
    > back to this but never did. Filemarks are sufficiently tricky that
    > when I last messed with them (2.2.8?) the SCSI and IDE tape drivers
    > did different things. I got confused and never got around to
    > resolving the confusion. The tricky part is that a write operation
    > followed by most any other operation really needs a filemark to be
    > written. I believe the problem was whether a write operation followed
    > by MTWEOF wrote one or two filemarks. Or something like that.
    > Anyhow, the difference revolved around whether one or two filemarks
    > got written (in the QIC-157 sense). And then the behavior of MTFSF
    > and MTBSF, including which side of the filemark you ended up on, and
    > whether one filemark was really two QIC-157 marks.
    > Anyhow, you can tell that 1) the memories are fuzzy, and 2) I'm a bit
    > confused. We (someone?) should probably figure out/decide what the
    > "right thing" to do is and try to make all the tape drivers do the
    > same thing, so that backup software writing a TR-4 tape on a SCSI
    > drive can read it back transparently on a parallel port drive.
    > -Scott Berg

    Actually, AFAICT, the whole weof process is taken care of by the drive and
    the QIC157 specifications. There's no real fiddling that has to be done,
    just send the command and the protocol and drive do the work. The same
    goes for the fsf and bsf commands. There might have to be some work done
    to get the fsfm and bsfm commands to put you where you want to be, but the
    QIC157 specs show specifically what needs to be sent in the packet to put
    you directly following count filemarks. So far I have actually just
    copied most of the code I have from either st.c or ide-tape.c. st.c has a
    more full set of mtops so I can get the way its done and then just
    substitue the proper codes from the QIC157 spec sheet. ide-tape.c makes
    things even easier because it even uses the correct packet commands.
    That's the weird thing about this whole process. This driver has been
    basically non-functional for so long and yet all the work has already been
    done by other people in other drivers.

    On another note, I think the problems with fsf and bsf from the last patch
    I sent should be fixed with the patch I have attached to this message.
    The problem was that I used a SCSI code instead of the QIC157 code.

    Russ Ingram
    Gargoyle Computer Consulting

    -- To unsubscribe, send mail to: -- -- with the single word "unsubscribe" in the body of the message. --

    This archive was generated by hypermail 2b29 : Fri Jun 15 2001 - 00:56:37 EDT