3 Jan
2024
3 Jan
'24
12:49 a.m.
On Mon, Jan 1, 2024 at 9:00 AM Clem Cole <clemc(a)ccc.com> wrote:
Yea. I'd be quite keen on the details before Sun's scheme, which was the
first I could find in the artifacts we have today. But there's so many
artifacts they are all hard to go through. Especially scanned manuals that
have no OCR encodings...
I did find the SunOS 0.x images (UniSoft V7 port) didn't appear have a disk
What's MK0? Is that the group at DEC that did Unix?
Warner -- thanks...
On Sun, Dec 31, 2023 at 5:07 PM Warner Losh <imp(a)bsdimp.com> wrote:
I don't have access to anything but Ultrix-11 3.1 sources.
But there's no disk label stuff there. The dksizes.c file is just the
individual partition sizes removed from the respective driver and added to
dksize.c, presumably so it could be rebuilt easily w/o giving away any Unix
IP.
And the disktab stuff is way better than what came before. It enshrined
into a text file what the right partitions should be for each of the
devices. And even that took a lot of effort and would feed into the
defaults for partitioning disks when that came along.
Except I can't find any of this in our V7m or ultrix-11 that we have.
This is 2.1. And there all the device drivers still have the fixed tables:
....
and the ultrix-11 3.1 sources we have are similar, but move all of the
above into /usr/sys/conf/dksizes.c.
I remember dksizes.c -- I'll take your word for it being 3.X, not 2.X;
I'm
pretty sure that was the start of the work in Merrimack by Fred Cantor to
make things more independent. Shannon would have been aware of all of it,
and before he went to Sun, he and Jean were working with the folks at CSRG
(Sam, in particular), moving some of the DEC I/O support into BSD. Bill
Munson convinced his management that it was worth it for DEC to at least
make sure the DEC peripherals were being well handled and in mostly the
same manner. IIRC Jean spent 6-9 months embedded in the CSRG working on
much of that.
The early disktab stuff encoded the default tables
into a text file to
Yes. There's all kinds of compounding factors, as we saw play out when
old-school BSD disklabels started existing in a MBR world.
make it easier to cope with all the different
types of disks, but didn't
affect what we know as bsdlabels until after 4.3BSD.
Right.
The naming convention was there, but the
'write bits to the disk to
describe partitioning' I couldn't find at all in ultrix. I think you may be
confusing that stuff (which was a very clever way to cope with all these
disks that have different partitioning in a increasingly generic way) with
disk labeling which I think.
Quite possible.
The key is that partitioning the disk to allow its use for different
things and disk geometry support get all mixed together in the different
schemes. As we discussed, it often happens in multiple places (since the
ROMs, like the PC's BIOS, need at least some of the info at boot), and the
loaded OS (particularly ones with multiple OSs on them) might want to do
something completely different. This is why Grant's question is a
little hard to answer directly - as I said, it is a long, slow trip.
UNIX Partitioning, like what Dennis did, came first.
If you look at
PDP-11 and later Vaxen, the "disk support" for booting is pretty crude and
built into the ROM -- *i.e*., boot RP0 or RK0 -- the "disk geometry" is
hidden in the Boot ROM. But when so many disks start to show up using the
same controllers, the ROM needs to be smarter. So, some way to encode
geometry is needed. But Partitioning for the OS is still something that is
handy and so often got put into the same support (such as the PC's BIOS
tables - which were a good idea, poorly executed).
Yes. Dennis did it in like 75, and it wasn't until the mid to late 80s that
most disks had their partitioning encoded on the drive itself. Some of the
encoding schemes included the geometry of the device (some implicitly, some
explicitly), while others didn't. It was a real mess.
Sun was first to market with.
To be fair, Masscomp's "disk
geometry" code that Paul Cantrell wrote
pre-dated Sun by at least a year or more. I did not include it in my
history, as it is private to their boot ROM. Nice scheme, actually - but
proprietary, and I don't think any of the ideas went anywhere else - other
than later Sun ROMs supported a similar functionality, and they would have
at least seen them at customers and known about it, particularly since Sun
picked up the Xylogic disk and tape controllers that they developed for
Masscomp originally (Paul spent many hours at Xylogics helping with their
Microcode). The point is, by that time, the proliferation of different
disk manufacturers -- something to make the boot ROMs and OS's more
independent was forced on the different systems providers if they were
going to have any chance of being able to be flexible in the market/field.
I have no data on Masscomp's / Xylogic's ROMs, alas. And I know that
getting the geometry from the disk lived in the driver for a long time
because of issues like this, and why bootstrapping these machines were
always a complex affair. I don't recall there being any Xylogic specific
labels on the drives we had at Solbourne, though. And did Masscomp's stuff
write data to the media that was then used to figure out the geometry /
partitioning? Or was it still a largish table of drive model X has geometry
x/y/z (which PC BIOS had initially after the AT mainstreamed winchester
disks there).
Maybe you can help me find it?
I'll see what I can dig up.
partition, but
1.0 (post 4BSD pre 4.1BSD) and later did. That puts it at
1982. Although based off BSD, the disk label stuff wasn't in BSD for
another 5 years when the BSD folks started the Tahoe port.
Right, this is all of the MK0, CSRG, and Sun connection via Fred, Bill,
and Sam. At a minimum, they knew what the other was doing/had done, and
some of it definitely migrated.
WRT to OpenFW, my memory is that Larry points out that
Sun was the primary
driver. But a lot of the Motorola club got interested in using it, too,
during the "JAWS" timeframe. I am pretty sure that there were versions for
68K, 88K, and PPC, as well as the SPARC version from Sun. Somewhere I
have early source distribution.
Yea, I have a memory of the Sun 3 (68k) machines having a different ROM
than the Sun 4 (sparc) machines in the late 80s/early 90s with similar
interfaces, but the Sun 3's being simpler. Maybe I just worked with older
Sun 3's that didn't have a newer OpenFirmware.
Warner