From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: Free software and the future of support for Diamond products Date: 25 Sep 1992 01:40:24 GMT
In article <2dD802rK230r01@JUTS.ccc.amdahl.com> gab10@cd.amdahl.com (Gary A Browning) writes:
>ISC 2.2.1 supports my Irwin Floppy Tape. Since this came in the form as a
>new driver in its own patch, either the hooks to the scheduler were already
>in the O/S or it is unnecessary (An interesting note is that the original
>distribution claimed to support many different Floppy Tapes but did not.
>I'll bet Irwin supplied the driver to ISC. The new driver makes not claims
>at supporting any other manufacturers drives)
All SVR4 implementations support scheduling at realtime priorities -- and
actually, if you want to hack the scheduler tables, batch jobs, as well...
unfortunately, like additional system calls, this requires sources or hackery
to implement, since the tables are in an object module produced with "ld -o",
and there isn't a way to pull out the already-resolved symbols. At a guess,
I'd say they either supplied only a "Driver.o" to the configuration directory
/etc/conf/pack.d/<drivername>, along with a "space.c", and appropriate files
to init.d and sdevice.d. If they went whole hog and changed the tables, they
would have to give you a new /etc/conf/pack.d/kernel/os.o as well.
The lack of support for multiple types of drives is a result of the standard
not enforcing a drive initialization protocol. The way around this would be
to divide the drive into control and communication parts, and write a new
control part for each drive to be supported. ISC hasn't done this yet.
>If I had to make a guess, I would say that the time critical operations are
>performed in the driver without releasing the CPU. I believe the only thing
>that can interrupt the 386BSD interrupt handler is another interrupt. If it
>should raise the interrupt fence, you should not be interrupted. I would think
>that ISC would be similar.
This is correct, but not necessarily cleanly imlementable in 386BSD as it
currently stands.
The problem is that SVR4 supports "soft" realtime priorities. It's not that
you can't raise the fence... it's that you don't really want to. A sparkling
example of why this is true: tape backup of a remotely mounted file system
using the 386BSD tape drive. You can't disable network interrupts during the
backup operation. Timing on the tape device has to either be interruptable
and realtime (like the ISC/Irwin implementation), or interruptable,
non-reatime, and non-timing critical (like 386BSD and Wangtek or SCSI tapes).
>The Irwin Floppy Tape drive is not a streamer. It is necessary to preformat
>the tapes into 512 bytes blocks. Each block can be written without impacting
>the block after it on the tape. You can do random access operations. Think of
>it as an incredibly slow floppy. The point is that if the data for the
>next block does not arrive in time, the drive simply has to reposition
>before writing it.
That "simply" is pretty time consuming... it sounds too much like "if the
file has been migrated to tape, the tape robot 'simply' loads it back to
physical disk". I realize that it's not *quite* that time consuming... but
still, one of the biggest wins of using a tape drive is that it's faster than
using floppies; this generally means the ability to "stream" ...in other
words, having the data ready to go *before* it's needed by the tape drive
and not causing the to-tape latency to exceed the "streaming" threshold. Or
to put it another way, never stopping the tape when it's on a roll for lack
of data or processing time.
Terry Lambert
terry_lambert@npd.novell.com
terry@icarus.weber.edu