dan (07/25/82)
About 10 days ago I posted a complaint in net.unix-wizards about the unix convention for encoding programmable magnetic tape drive features (density and automatic rewind) in the special file names. I suggested that ioctl() be used to select these features and requested opinions from other news readers. I have received ten responses so far. Seven agreed with me. One thought that both the current system and control via ioctl() were both ugly but suggested no alternatives. One voted for the current system. The remaining response indicated no clear preference. One of the people who voted with me suggested that a opening a magnetic tape drive should be reset it to some standard state. This is exactly what I think should not be done. Magnetic tape drive characteristics should survive open() and close() so that a sophisticated utility program (one that knows all about the ioctl()s) could be used to set up a tape drive before an unsophisticated program is run. Very few programs would need to use ioctl()s. Existing programs (e.g. tar, dd, tp, and cpio) would not need to be changed. Tape drive characteristics could be reset to some standard (I favor 1600 bpi without automatic rewind) when the drive is assigned.
smb (07/26/82)
Dare I suggest that UNIX follow the OS/360 model? Well, let me cite Multics instead -- it's a bit nicer, and there UNIX's debt is clear. Most of the time, I want to treat a file on a tape as a *file*. I rarely care about where on the tape it's located -- I want to find it, and read it, as many times as necessary to do what needs to be done. For example, I rarely extract a tar image without looking at the contents first; I *never* do if I'm running as root (and when will someone write some mods to tar that will let it rename files...?). When you mount a tape in OS/360 or Multics, you specify a file number. The operating system finds the file; when you close the tape drive, it repositions the tape to the start of that same file. You can read it over and over again if you'd like. (Both Multics and OS allow "labelled tapes"; Multics permits you to specify the file-name on the tape instead of the sequence number, while OS requires that they match.) There should be ioctl() calls to change the standard file number; calls like "write tape mark" should automatically increment it. Tape motion calls should of course exist -- but they should co-exist with this basic principle. Thus, 'backspace record' should halt at the tape mark -- you can't seek past the beginning of a file. But 'rewind' should reset the file number to 1. (Amdahl's UTS system has some of this implemented, though not the file-number concept. One nice thing they do do is generate a signal when a write encounters the end-of- volume mark -- the same signal they use to indicate that you've just filled up a file-system, duckie.)
ARPAVAX:mo (07/26/82)
I have a triple-density tape drive and adding support for that simply exacerbates the already silly state of affairs. I do have a proposal, however. We must keep the current randomness for compatability, but I think we can implement my proposal concurrently. The only complication is that the TU78 driver on 4.1BSD has usurped "mt" as a device name. That not withstanding, create a series of devices, call them "tapeN", one per TRANSPORT, where the N indicates the transport. These are minor devices which have the following characteristics. There is a transport state table which records the "default" values of density and "rewindedness" (and anything else we might want to include, such as file position). When these "generic" devices are opened, the transport is conditioned to the saved state. The existing "mt" command can easily be extended to specify a density (honored on output, or input, too, if the drive doesn't autoselect) and the rewind control. The file position stuff could be added too, but that makes the opens do more work. If the filepositioning were added, rewinds might honor that too. However, I really think things beyond density and rewindeness should be done with a process sitting in front of the tapedrive, much like the VMS tape ACP. This would let Unix handle "standard labelled tapes" (in their miriad of standard formats) without the tape driver turning into another TTY driver. This would allow specifying a "virtual" start-of-tape and rewinds proceed back to that point. It would also allow embedded file names, as a result of handling labelled tapes. While this is tricky to do in general, the 4.2 IPC mechanisms should be up to the task. I intend to find out when I get my tape!! -Mike PS - plz excuse misspelling of "myriad". Don't know how to make this God-forsaken composition program let me edit my text, and Lord knows there ain't no manual page!!! Maybe if some of the Netnews creators had ever used a REAL mail system some of this would be better. (end of flame)
nrh (07/26/82)
Choke! GASP! OS/360? Look, the tape drive stuff works fine! Sure, it doesn't have a million options to make a tape look like a particular file number, to send you a signal when you try to read past end-of-file, and so forth, BUT IS THAT WHAT YOU WANT? Or do you want the 90% of usefulness for 10% of the complexity that UNIX is so good at? Isn't the entropic bristling of the tty driver enough? Must the tape drive stuff start expanding too? yours for simplicity, - Nat Howard