From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 17994 invoked from network); 2 Jan 2024 18:50:30 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 2 Jan 2024 18:50:30 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 24EBB43E9A; Wed, 3 Jan 2024 04:50:23 +1000 (AEST) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by minnie.tuhs.org (Postfix) with ESMTPS id 086CA43E92 for ; Wed, 3 Jan 2024 04:50:10 +1000 (AEST) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a2358a75b69so1657573966b.1 for ; Tue, 02 Jan 2024 10:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704221408; x=1704826208; darn=tuhs.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xdsJ2/l0jlj4S3RMsaNELcEVyqgKNMIUTTkQeTCi/Pg=; b=O9ekBbM8AQBOefcIzu9nWE5hgijQC5IdzP83aVRxNn6jVZcMAiqkX665vIdvT9XhlA zdvtlkg7oWtFPzYjg62rdF/4dfnOGVdtZnKfrnOJYKwy70eKSVEB+4JR1A8tvFOKH45V jr2H8qA34I3I826xQ5asOxe4wakaSQzm9Rc8bG+Z3bJF0Hs9Nxe69YPr3HilCGnWrcC2 AKH7pMkXVlzJaNrJh3LTkENoyZHD3SqIRyD8EhwZ+ulH/yCbIT/Hx8/SpDeFdqnRVWU7 8qSP6fSWDJZHdo/n8u6KifEs+0/I+mVVfGZquD5XbQI2xWEGW1SqigMz9Fv7ns6p5giT MqsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704221408; x=1704826208; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xdsJ2/l0jlj4S3RMsaNELcEVyqgKNMIUTTkQeTCi/Pg=; b=GohCYJDvDvUHOaZd0m38VX7ZN1bhOxq9ISX9k/9Umris/SA3VI5S/IdZTLvaPgB1OT xQ/gyymNvgsvaYVsfx0x9ZLi1X+dVZYwqfGkje8UsWkjpUTdyhr8Jbz/3H7AxPqt5ZlQ c3Ql68pWpBgdFEI7dr9zSYuvU44DjxmDo7wZqDEh/RElqovWKGwYc+Kw4h4N4eLj6EL1 t9Anod0N08zTHD3NNOI06WXmnOgf9ZCb4V2iTp3FvM2UM8xc1OL6r9kw22CQ581n3gOe HYj4Bv8Jff0MbGSXXRCFLkeGvwIJ77NvSieg5jLSp83y+bihzqp1khlq1k0gkk2o+IVW j9LQ== X-Gm-Message-State: AOJu0Yz72S/A/hVVjGjiiwS01ZmlBS+h8TcJ8lx0bv1BMBYaNUtlnlnq cmLn0A6dOWS+U8Wi2o1kwrzlS66Et6QnTWAoSo9t91PivZkPGQ== X-Google-Smtp-Source: AGHT+IFKLq10szm0BVxkGRHZ9u4D1z7vwCbEjbt5N9Q0gF/aW580+99BwObFFK06b/IrSzF7NlaZy0XDwKPRhdOdb4I= X-Received: by 2002:a17:906:ef08:b0:a27:7602:2c6a with SMTP id f8-20020a170906ef0800b00a2776022c6amr11196571ejs.36.1704221407995; Tue, 02 Jan 2024 10:50:07 -0800 (PST) MIME-Version: 1.0 References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> In-Reply-To: From: Warner Losh Date: Tue, 2 Jan 2024 11:49:56 -0700 Message-ID: To: Clem Cole Content-Type: multipart/alternative; boundary="000000000000a475f2060dfaf782" Message-ID-Hash: UMCHA5PKYS6H6YJC7L4UQXFGDS4USNS5 X-Message-ID-Hash: UMCHA5PKYS6H6YJC7L4UQXFGDS4USNS5 X-MailFrom: wlosh@bsdimp.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Grant Taylor , The Unix Heritage Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Question about BSD disklabel history List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000a475f2060dfaf782 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 1, 2024 at 9:00=E2=80=AFAM Clem Cole wrote: > > Warner -- thanks... > > On Sun, Dec 31, 2023 at 5:07=E2=80=AFPM Warner Losh wrot= e: > >> >> >> 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 table= s: >> .... >> >> 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 CSR= G > (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. > 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. > The early disktab stuff encoded the default tables into a text file to >> 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) wi= th >> 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 th= e > ROMs, like the PC's BIOS, need at least some of the info at boot), and th= e > 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. > Yes. There's all kinds of compounding factors, as we saw play out when old-school BSD disklabels started existing in a MBR world. > 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 an= d > 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 t= he > 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 - othe= r > than later Sun ROMs supported a similar functionality, and they would hav= e > at least seen them at customers and known about it, particularly since Su= n > 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. > 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 >> 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. > What's MK0? Is that the group at DEC that did Unix? > WRT to OpenFW, my memory is that Larry points out that Sun was the primar= y > 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 f= or > 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 --000000000000a475f2060dfaf782 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 1, 2024 at 9:00=E2=80=AFA= M Clem Cole <clemc@ccc.com> wrot= e:
=
Warner -- thanks...

On Sun, Dec 31, 2023 at 5:07= =E2=80=AFPM Warner Losh <imp@bsdimp.com> wrote:


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 d= rivers still have the fixed tables:
....

=
and the ultrix-11 3.1 sources we have are similar, but move all of the= above into=C2=A0/usr/sys/conf/dksizes.c.
I remember dksizes.c -- I'll take your wo= rd 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 th= e DEC I/O support into BSD.=C2=A0 =C2=A0Bill Munson convinced his managemen= t that it was worth it for DEC to at least make sure the DEC peripherals we= re being well handled and in mostly the same manner.=C2=A0 IIRC Jean spent = 6-9 months embedded in the CSRG working on much of that.

I don't have access to an= ything but Ultrix-11 3.1 sources.

But there's = no disk label stuff there. The dksizes.c file is just the individual partit= ion sizes removed from the respective driver and added to dksize.c, presuma= bly 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 def= aults for partitioning disks when that came along.
=C2=A0
The early disktab stuff encoded th= e default tables into a text file to make it easier to cope with all the di= fferent types of disks, but didn't affect what we know as bsdlabels=C2= =A0until after 4.3BSD.
Right.<= /div>
=C2=A0
The naming convent= ion 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 th= at stuff (which was a very clever way to cope with all these disks that hav= e 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 toget= her in the different schemes.=C2=A0 =C2=A0As 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 multip= le OSs on them) might want to do something completely different.=C2=A0 =C2= =A0 =C2=A0This is why Grant's question is a little hard to answer direc= tly - as I said, it is a long, slow trip.

Yes. There's all kinds of compounding fac= tors, as we saw play out when old-school BSD disklabels started existing in= a MBR world.
=C2=A0
UNIX Partiti= oning, like what Dennis did, came first.=C2=A0 If you look at PDP-11 and la= ter Vaxen, the "disk support" for booting is pretty crude and bui= lt into the ROM -- i.e., boot RP0 or RK0 -- the "disk geometry&= quot; is hidden in the Boot ROM.=C2=A0 =C2=A0But when so many disks start t= o show up using the same controllers, the ROM needs to be smarter.=C2=A0 So= , some way to encode geometry is needed.=C2=A0 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 execute= d).

Yes. Den= nis did it in like 75, and it wasn't until the mid to late 80s that mos= t disks had their partitioning encoded on the drive itself. Some of the enc= oding schemes included the geometry of the device (some implicitly, some ex= plicitly), while others didn't. It was a real mess.
=C2=A0
Sun was first to market with= .
To be fair= , Masscomp's=C2=A0"disk geometry" code that Paul Cantrell wro= te pre-dated Sun by at least a=C2=A0year or more.=C2=A0 I did not include i= t in my history, as it is private to their boot ROM.=C2=A0 Nice scheme, act= ually - but proprietary, and I don't think any of the ideas went anywhe= re else - other than later Sun ROMs supported a similar functionality, and = they would have at least seen them at customers and known about it, particu= larly since Sun picked up the Xylogic disk and tape controllers that they d= eveloped for Masscomp originally (Paul spent many hours at Xylogics helping= with their Microcode).=C2=A0 =C2=A0=C2=A0The point is, by that time, the p= roliferation of different disk manufacturers -- something to make the boot = ROMs and OS's more independent was forced on the different systems prov= iders 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=C2=A0/ Xylogic's=C2=A0ROMs, al= as. 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 ma= chines were always a complex affair. I don't recall there being any Xyl= ogic specific labels on the drives we had at Solbourne, though. And did Mas= scomp's=C2=A0stuff 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 mainst= reamed winchester disks there).
=C2=A0
=C2=A0

Maybe you can help = me find it?
= I'll see=C2=A0what I can dig up.

Yea. I'd be quite keen on the deta= ils before Sun's scheme, which was the first I could find in the artifa= cts we have today. But there's so many artifacts they are all hard to g= o through. Especially scanned manuals that have no OCR encodings...

I did find the SunO= S 0.x images (UniSoft V7 port) didn't appear have a disk partition, but= 1.0 (post 4BSD pre 4.1BSD) and later did. That puts it at 1982. Although b= ased off BSD, the disk label stuff wasn't in BSD for another 5 years wh= en the BSD folks started the Tahoe port.
=
Right, this is all of the MK0, CSRG, and Sun connection via Fred, B= ill, and Sam.=C2=A0 At a minimum, they knew what the other was doing/had do= ne, and some of it definitely migrated.

What's MK0? Is that the group at DEC that d= id Unix?
=C2=A0
WRT to OpenFW, my= memory is that Larry points out that Sun was the primary driver.=C2=A0 =C2= =A0But a lot of the Motorola club got interested in using it, too, during t= he "JAWS" timeframe.=C2=A0 I am pretty sure that there were versi= ons for 68K, 88K, and PPC, as well as the SPARC version from Sun.=C2=A0 =C2= =A0Somewhere I have early source distribution.=C2=A0=C2=A0

<= /div>

Yea, I have a memory of the Sun 3 (68= k) machines having a different ROM than the Sun 4 (sparc) machines in the l= ate 80s/early 90s with similar interfaces, but the Sun 3's being simple= r. Maybe I just worked with older Sun 3's that didn't have a newer = OpenFirmware.

Warner=C2=A0
--000000000000a475f2060dfaf782--