mogul@CSL-Vax.ARPA (Jeff Mogul) (08/28/84)
In the mtio(4) manual page for 4.2BSD, it is stated that "The files mt0, ..., mt7 are 800bpi, mt8, ..., mt15 are 1600bpi, and mt16, ..., mt23 are 6250bpi." This is a change from the corresponding 4.1BSD manual page, mtop(4), in which it is stated that "The files mt0, ..., mt7 are low density, and mt8, ..., mt15 are high density." This change seems to be a good idea, since it means that the mapping from minor device number to density is now independent of the particular hardware. Unfortunately, the change did not make it into the TU78 driver, which still believes that /dev/rmt0 is a 1600bpi device, and /dev/rmt8 is 6250bpi. There are two ways of resolving this conflict (if you don't count "change the manual page" as an option): (1) Fix the device driver (2) Modify /dev/MAKEDEV so that /dev/rmt8 is on minor device 0 /dev/rmt16 is on minor device 8 My preference is to fix the device driver (which involves a one-word change to the source code), but I wondered if anybody had a good reason for taking the other approach. Another question arises: what minor devices should mt0, ..., mt7 map on to for the TU78? The only other 6250bpi tape supported in the 4.2BSD distribution is the "ut" tri-density drive, which has an 800bpi setting and thus a natural choice for mt0. The TU78, however, does not work at 800bpi. The choices I see for mt0 are (1) Leave it as it is (1600 bpi) (2) Remove it from /dev The latter avoids conflict with the language of mtio(4); the former avoids confusing the poor users. Any comments? -Jeff Mogul decvax!decwrl!Shasta!mogul mogul@Shasta.ARPA
woods@hao.UUCP (Greg "Bucket" Woods) (08/30/84)
Yes, there is a very good reason for changing the man page instead of
"fixing" the device driver. We have many locally-written shell scripts which
will break if the fix is installed. I'll bet we aren't the only ones, either.
--Greg
--
{ucbvax!hplabs | allegra!nbires | decvax!stcvax | harpo!seismo | ihnp4!stcvax}
!hao!woods
"... the heat come 'round and busted me for smiling on a cloudy day..."chris@umcp-cs.UUCP (Chris Torek) (08/30/84)
With a TU77 *and* a TU78, we had to do something even more different.
We made mt0 the TU77 at 800 BPI, mt8 the 77 at 1600, mt1 the 78 at
1600, and mt9 the 78 at 6250. Our /dev entries don't all correspond to
the minor device numbers since the two drives are on different
formatters (naturally).
We found that typing ``/dev/rmt13'' all the time was a pain, so we made
links called mu0, mu4, mu8, mu12 (and rmu versions of the same) and use
'alias mu "mt -t /dev/rmu12"'.
Personally, I think there should be two /dev names for every raw tape
drive at every density: the ``standard'' one (rmt0 etc.) and a
``verbose'' one (/dev/tu77_800 or some similar garbage).
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@marylanddmmartindale@watcgl.UUCP (Dave Martindale) (09/01/84)
One way of "fixing" the discrepancy is to get rid of the un-mnemonic names for tape drives entirely. Several years ago, the tape naming convention was changed at Waterloo. The name for a /dev entry for a tape contain the always-present core "mt". To that is appended "800", "1600", or "6250" depending on the density, followed by a letter indicating which of possibly many drives on the machine is intended. When desired, a "r" is prepended to get the name of the raw tape, and prepending an "n" to the whole thing gives the name for the no-rewind-on-close device. Thus "/dev/rmt1600a" is the "A" (only or best) tape drive at 1600BPI using the raw interface. "/dev/nrmt6250b" is the second drive at 6250, no rewind. There is no hint of what controller each drive is on - the user doesn't care. And drives that don't support certain densities simply don't have entries for them. Programs that have default tape names compiled in (tar, etc) now default to "/dev/rmt1600a". With any scheme like this, the attributes that the user wants to control are specified by the name in a way that the user has a chance of remembering. And the mapping between these attributes and the actual minor device numbers used is an arbitrary convention that only the driver in question and /dev/MAKEDEV need agree on.
lew@t4test.UUCP (Lew Mullen) (09/04/84)
Hasn't anyone heard of threee-density tape drives ? (800/1600/6250) If you define "high/low" what happens to "middle" ?