TUHS

tuhs@tuhs.org

32 participants
6435 discussions

Re: [TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

by norman＠oclsc.org

/dev/makefile on the V7 distribution tape (or at least the unpacked image I have that I believe to be same) says: ht: /etc/mknod mt0 b 7 64 /etc/mknod mt1 b 7 0 /etc/mknod rmt0 c 15 64 /etc/mknod rmt1 c 15 0 /etc/mknod nrmt0 c 15 192 /etc/mknod nrmt1 c 15 128 chmod go+w mt0 mt1 rmt0 rmt1 nrmt0 nrmt1 According to /usr/sys/dev/ht.c, the minor device number was used as follows: minor(dev) & 07 slave unit number minor(dev) & 070 controller unit number minor(dev) & 0100 tape … [View More]density: set == 800 bpi, clear 1600 minor(dev) & 0200 no-rewind flag It takes some digging in the source code (and the PDP-11 Peripherals Handbook) to understand all this numerology. In most of the code, minor(dev) & 077 is just treated as a unit number (fair enough). The use of 0200 appears only as a magic number in htopen; that of 0100 only as a magic number in htstart, and that only implied: the test is not minor(dev) & 0100, but unit = minor(bp->b_dev) & 0177; if(unit > 077) Not so bad when the whole driver is only 376 lines of code, but it wouldn't have hurt to make it 400 lines if that meant fewer magic numbers. Anyway, what all this means is that /dev/*mt0 and /dev/*mt1 both actually meant slave 0 on TU16 controller 0, but mt0 was 800 bpi and mt1 1600 bpi. Hence, I would guess, tar's default to mt1. My first exposure to the insides of UNIX was in the High Energy Physics group at Caltech. Some of our systems had multiple tape drives and every drive supported multiple densities, so we invented for ourselves a system like that many other sites invented, with names like /dev/rmt3h to mean the third tape drive at high density. (Hence the USG naming scheme of /dev/rmt/3h and the like--not that we taught it to them, just that many places had the same idea.) Our world wasn't nearly as exciting as that of our neighbors, across the building and three floors down, in the Space Radiation Laboratory. They had a huge room full of racks of magtapes full of data from satellites, and many locally- written tools for extracting the data so researchers could work on it. The hardware was an 11/70 with eight tape drives, and at any given time at least half the the drives would be spinning. One of the drives was seven-track rather than nine-track, because some of the satellite data had been written in that format. Fair disclosure: I had a vague memory that the `drive number' in the device name had been recycled for other purposes, but couldn't remember whether it was density or something else. (I'm a little surprised none of the other old-timers here remembered that, but maybe I worked with tapes more than them.) But I had to dig into the source code for the details; I didn't remember all that. And I did have to climb up to the high shelf in my home office for a Peripherals Handbook to understand the magic numbers being stuffed into registers! Norman Wilson Toronto ON [View Less]

9 years, 2 months

Re: [TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

by Doug McIlroy

> I have no memory of why Ken used mt1 not mt0. Doug may know. I don't know either. Come to think of it, I can't remember ever using tar without option -f. Direct machine-to-machine trasfer, e.g. by uucp, took a lot of business away from magtape soon after tar was introduced. Incidentally, I think tar was written by Chuck Haley or Greg Chesson, not Ken. Doug

9 years, 2 months

Re: [TUHS] TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

by Doug McIlroy

Forget that I said, "I think that tar was written by Chuck Haley or Greg Chesson". Ken confirms that he wrote it, for dectape. Doug

9 years, 2 months

Re: [TUHS] Pre-v6 images and 2.11BSD patches

by Johnny Billquist

On 2015-12-12 07:16, William Pechter<pechter(a)gmail.com> wrote: > > Warren Toomey wrote: >> >On Sat, Dec 12, 2015 at 03:54:16PM +1100, Peter Jeremy wrote: >>> >>Also, I've seen suggestions that there's a 2.11BSD patch later than >>> >>447 but I can't find anything "official" andwww.2bsd.com is either >>> >>down or inaccessible from all the systems I have access to. Does >>> >>anyone know if 448 or later were … [View More]

9 years, 2 months

Re: [TUHS] why is sum reporting different checksum's between v6 and v7

by jnc＠mercury.lcs.mit.edu

> From: Random832 > Interestingly, the SysIII sum.c program, which I assume yields the same > result for this input, appears to go through the whole input > accumulating the sum of all the bytes into a long, then adds the two > halves of the long at the end rather than after every byte. That's the same hack a lot of TCP/IP checksums routines used on machines with longer words; add the words, then fold the result in the shorter length at the end. The one I wrote … [View More]

9 years, 2 months

Re: [TUHS] why is sum reporting different checksum's between v6 and v7

by jnc＠mercury.lcs.mit.edu

> From: Will Senn > I noticed that the sum utility from v6 reports a different checksum > than it does using the sum utility from v7 for the same file. > ... does anyone know what's going on here? > Why is sum reporting different checksum's between v6 and v7? The two use different algorithms to accumulate the sum (I have added comments to the relevant portion of the V6 assembler one, to help understand it): V6: mov $buf,r2 / Pointer to buffer in R2 2: … [View More]

9 years, 2 months

where is the v6tar source?

by Mark Longridge

Ok, it definitely sounds like the v6tar source is around somewhere so if someone could point me in the right direction... I've only seen the binary, and I can't remember where I got it. Mark

9 years, 2 months

why is sum reporting different checksum's between v6 and v7

by Will Senn

All, While working on the latest episode of my saga about moving files between v6 and v7, I noticed that the sum utility from v6 reports a different checksum than it does using the sum utility from v7 for the same file. To confirm, I did the following on both systems: # echo "Hello, World" > hi.txt # cat hi.txt Hello, World Then on v6: # sum hi.txt 1106 1 But on v7: # sum hi.txt 37264 1 There is no man page for the utility on v6, and it's assembler. On v7, there's a manpage and … [View More]

9 years, 2 months

why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

by Will Senn

All, In my exploration of v6, I followed the advice in "Setting up Unix - Seventh Edition" and copied v6tar from v7 to v6. Life is good. However, tar is using mt1 and it is hard coded into the source, tar.c: char magtape[] = "/dev/mt1"; As the subject line suggested, I have two questions for those of you who might know: 1. Why is it hard coded? 2. Why is it the second device and not the first? Interestingly, it took me a little while to figure out it was doing this because I … [View More]

9 years, 2 months

ld (was v6tar from v7 on v6, too large?)

by Doug McIlroy

That's exactly right. ld performs the same task as LOAD did on BESYS, except it builds the result in the file system rather than user space. Over time it became clear that "linker" would be a better term, but that didn't warrant canning the old name. Gresham's law then came into play and saddled us with the ponderous and misleading term, "link editor". Doug > My understanding, which predates my contact with Unix, is that the > original toochains for single-job machines consisted of the … [View More]

9 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS