From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: Free software and the future of support for Diamond products Date: 20 Sep 1992 09:58:50 GMT
In article <1992Sep20.030148.17766@westford.ccur.com> mod@westford.ccur.com (Michael O'Donnell 508-392-2915) writes:
>I recently heard conflicting stories about the folks who make
>those little Colorado tape drives that connect to the PC floppy
>controller; a friend said they won't tell you anything, but a
>computer store tech said they were reasonable folks. I haven't
>gotten around to checking it out for myself, yet. Does anybody
>know enough about how to program those drives to enable me to
>write a device driver?
The standard is public. The problem is timing, which, if you think about it,
makes sense.
A DOS machine is prety stupid -- it doesn't have to run other applications
at the same time as a QIC-40/QIC-80 driver. It runs only the driver.
The main deficiency of this under a UNIX or UNIX-like OS should be obvious:
Rather than the driver being part of the archive software, and reading from
a static file system image (ie: directly from the disk/file being backed up),
a UNIX driver would have to give enough time to tar (or some other archive
program) and the disk I/O subsystems (file system, VFS, system call interface,
pager, and disk device driver) and still *always* be just about to write the
next block when the tape drive needs it. The driver wouldn't have enough
influenc on the scheduler to distinguish "tar" from "xtank", since both are
user processes. Thus either an enforced single user mode with limited
running of daemons, or suspension of all non-archive related processes during
tape access would have to occur.
You can call this a scheduler problem (in that a meticulously rewritten
scheduler should be able to cope, given several man-years of design and
implementation), or you can call it a problem with what makes the hardware
so cheap in the first place (it's stupid and has only enough smarts to talk
to a floppy controller, which is generally no Albert Einstein to begin with).
It should be possible if you were to write a file system reader/archival
program as a standalone image, and then provide some way of booting to it
instead of 386bsd. This is a lot of work, since (exactly the same as DOS)
each file system format to be backed up requires a seperate program, as the
backup program must have file system reading and writing code built into it.
This would be roughly equivalent to running a single program (the UNIX archiver
vs. the DOS archiver).
The wonderful thing about this is, it must also know about bad sector
forwarding in file systems supporting the concept, if it is to be able to
do anything other than device image save restore (say a single file restore).
Nobody (that I know of) has found the relatively small diffence in price for
a SCSI or Wangtek tape drive worth going to that much effort.
If you go with a commercial product, where development costs can be amortized
across a product price for more than one user, then the reward may justify
the capital outlay in time. Specifically, I don't know what BSDI has done
regarding this -- I assume it would depend on customer demand. I am also
unaware of what Colorado or other vendors would think of writing the driver
for us and providing it when we bought hardware... probably very little,
since a Colorado driver doesn't require you to buy Colorado hardware.
So: you can undertake one of several tasks of varying degrees of difficulty,
you can con someone else into doing the work, or you can spring the extra
money for a drive that doesn't have such tight requirements.
My $0.02 on the subject...
Terry Lambert
terry_lambert@gateway.novell.com
terry@icarus.weber.edu