Date: Fri, 25 Apr 1997 17:24:32 -0500 (CDT) From: joed@ksu.edu To: terry@lambert.org (Terry Lambert) Cc: hackers@freebsd.org Subject: Re: Maintainer of ft/lft Message-ID: <199704252224.RAA07050@abc> In-Reply-To: <199704252054.NAA04073@phaeton.artisoft.com> from "Terry Lambert" at Apr 25, 97 01:54:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
As Terry Lambert wrote: > > > Biggest problem with the QIC stuff is that there are too many > > "standards". Also, it has to cooperate with the ft driver and > > allowing them to be active concurrently is a nuisance (though > > I think desirable). > > What? A QIC-117 device is a QIC-117 device is a QIC-117 device > is the argument that's been going on. If it *is*, then it doesn't > have to "cooperate" with anything... it *is* the replacement for > the ft driver. Conversely, if cooperation is required, then a > QIC-117 drive is *not* a QIC-117 drive is *not* a QIC-117 drive > (which is what I was chewed out for claiming). A QIC-40,80,3010,3020 device all use the QIC-117 command interface. One problem I came across was digging up the the geometry of the tape that is inserted in your drive... New revisions of QIC-117 have the interface necessary to ask "hey what's the geometry" and the drive will return enough data for you to calculate everything you need to know. As I mentioned in my last email the code becomes harder if you use a QIC-80 rev a or b (possibly c, not sure anymore), as those drives don't provide the method of detecting tape geometry (There wasn't a need then). You will need more than QIC-117 to implement the driver. At the least you will need QIC-40, QIC-80, QIC-117, QIC-3010, QIC-3020. There are a couple other QIC's you will need to handle ecc and maybe some for compression. Again it's been a bit since I've looked. Whenever you call QIC up asking for copies of the standards ask them to send you a copy of their matrix that shows all the standards. > If I can't have one driver per standard, then it's not a standard. > It's more like a set of standards like you have a set of .c files in a driver. I handle this type of drive, I handle that type of drive, I'm the command syntax, etc etc. > I was under the impression that it was being claimed to be a standard; > if so, the bogusness of the current ft/lft driver in FreeBSD derice > from it being logically incomplete, not from any fault of the > manufacturer. > Once upon a time ft/lft was more accurate, but the original standards didn't scale well, if at all. In order to handle bigger badder tape drives (250Mb just don't cut it anymore ;) the standards needed some work. Writing a driver to handle todays standards should be easy, but you'll need some hooks to handle the old drives that aren't up to standard. In the ft0 driver the original author made a comment while working on establishing the tape geometry that his colorado jumbo 250 didn't work with the nicer commands. As much as it would be nice to forget the old tapes, I'm guessing there are a lot of jumbo 250s running around. It would be nice if our ft0 could handle those. > As I said before, if this is the case, I will personally go buy the > IOmega version of the cruddy on-SCSI hardware to let me hack on the > driver, as long as I can get documentation without signing non-disclosure > and making it impossible to hand off the driver and never look at it > again. All QIC standards are freely available at the request, with no non-disclosure agreements required. It is a fairly open standard. --- Joe Diehl <joed@ksu.edu> PGP Key: finger joed@unix.ksu.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704252224.RAA07050>