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_FONT_LOW_CONTRAST,HTML_MESSAGE,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9449 invoked from network); 1 Jan 2024 16:01:04 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 1 Jan 2024 16:01:04 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 037F443EC0; Tue, 2 Jan 2024 02:00:56 +1000 (AEST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) by minnie.tuhs.org (Postfix) with ESMTPS id 8926143EAA for ; Tue, 2 Jan 2024 02:00:44 +1000 (AEST) Received: by mail-qk1-x736.google.com with SMTP id af79cd13be357-781600ab3d8so395023485a.0 for ; Mon, 01 Jan 2024 08:00:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; t=1704124843; x=1704729643; 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=IA5kZUWvrw3nIwS78whnZYaTA8t39ksfEmGXY2qdEmI=; b=dnW7bxRdMXZiB5lz2DAeuSEMEBd7DpgESzhsEmzYFk1ocxUgYqijNtQn+BV2FjlPxj 3ZxXtBNf6rANSQ3MR6e5C2a4SvJkNlvvOlrJpAR9O9CpgLEoH/kCmF5lqD5CcI8BiX5U rack1pEB/EyRt42lWNLLMHR1pJqqKf0So5Wp4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704124843; x=1704729643; 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=IA5kZUWvrw3nIwS78whnZYaTA8t39ksfEmGXY2qdEmI=; b=hjRlXdJMXdBkPNyPtubprnIzg508P0WwWaVIp/yzGoNaKnosZzuQOebV0LR9t8Knso lXkNe1xipVvvLVSPiAd+TPIXT3MTNKt8cjEvcrDU6QSOAgRSuIjqW436peDmlmWWs1ky ASM4k7O6PxkQKrKQ2BQTpNjJlgV6Hvzle7H7yeOR9iXrKVi+7wsYg8KPJcSe+u3DNyDK 6IX4wBZ4tDDlJYiExbIpW3xdZiLqmpZByY8Ed6GgFk6gAmeKSdG2uAr1S/5CvHDAJkLU cFskaY5RXwvWEBL86dZNh4Ua9hnytElbU4zc5cJEVIviYOAVnCENtO4x9Qm+5Tgu/4r/ N7KA== X-Gm-Message-State: AOJu0YzjKroVyZaXmvuKszJXRBS7L65h3+YM4OQ3tlrL/Tgl0GzxJZI9 qKMqfevFd7fQ67/5X7uTm7YH6FZuZqUfjgwRy+2HFR+/2LDx X-Google-Smtp-Source: AGHT+IF1j7I8RXk58ZCZUlo7OFwLb0DgF5nYYUK5hBdkw8xMrTxrTlnXT7r06lL00UjzvpixfMbfHUNfJCcpWvP9YtM= X-Received: by 2002:ae9:f10d:0:b0:781:a11f:d294 with SMTP id k13-20020ae9f10d000000b00781a11fd294mr5798128qkg.116.1704124843238; Mon, 01 Jan 2024 08:00:43 -0800 (PST) MIME-Version: 1.0 References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> In-Reply-To: From: Clem Cole Date: Mon, 1 Jan 2024 11:00:07 -0500 Message-ID: To: Warner Losh Content-Type: multipart/alternative; boundary="000000000000ef3d3f060de47b8d" Message-ID-Hash: QAWJ2VHFDGPGCAK4JOKTQKEKTWLLCHVI X-Message-ID-Hash: QAWJ2VHFDGPGCAK4JOKTQKEKTWLLCHVI X-MailFrom: clemc@ccc.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: --000000000000ef3d3f060de47b8d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Warner -- thanks... On Sun, Dec 31, 2023 at 5:07=E2=80=AFPM Warner Losh wrote: > > > Except I can't find any of this in our V7m or ultrix-11 that we have. Thi= s > 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 > 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) wit= h > 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). > 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. > > Maybe you can help me find it? > I'll see what I can dig up. > > 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 i= t > 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. =E1=90=A7 =E1=90=A7 --000000000000ef3d3f060de47b8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Warner -- thanks...

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

<= div>
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 ultri= x-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 word for it being 3= .X, not 2.X; I'm pretty sure that was the start of the work in Merrimac= k by Fred Cantor to make things more independent. Shannon would have been a= ware 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.=C2=A0 =C2=A0Bill Munson convinced his management that it was wor= th it for DEC to at least make sure the DEC peripherals were being well han= dled and in mostly the same manner.=C2=A0 IIRC Jean spent 6-9 months embedd= ed in the CSRG working on much of that.



= 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 af= fect what we know as bsdlabels=C2=A0until after 4.3BSD.
Right.

=C2=A0
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 wa= s a very clever way to cope with all these disks that have different partit= ioning in a increasingly generic way) with disk labeling which I think.
Quite possible.<= /font>

The key is that partitioning the disk to allow its use for differen= t things and disk geometry support get all mixed together 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 b= oot), and the loaded OS (particularly ones with multiple 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 directly - as I said, it is= a long, slow trip.

UNIX Partitioning, like what Dennis did, came f= irst.=C2=A0 If you look at PDP-11 and later Vaxen, the "disk support&q= uot; for booting is pretty crude and built into the ROM -- i.e., boo= t RP0 or RK0 -- the "disk geometry" is hidden in the Boot ROM.=C2= =A0 =C2=A0But when so many disks start to show up using the same controller= s, the ROM needs to be smarter.=C2=A0 So, some way to encode geometry is ne= eded.=C2=A0 But Partitioning for the OS is still something that is handy an= d so often got put into the same support (such as the PC's BIOS tables = - which were a good idea, poorly executed).

=C2=A0

=

=C2=A0
Sun was firs= t to market with.
To be fair, Masscomp's=C2=A0"disk geometry" code that P= aul Cantrell wrote pre-dated Sun by at least a=C2=A0year or more.=C2=A0 I d= id not include it in my history, as it is private to their boot ROM.=C2=A0 = Nice scheme, actually - but proprietary, and I don't think any of the i= deas went anywhere else - other than later Sun ROMs supported a similar fun= ctionality, and they would have at least seen them at customers and known a= bout it, particularly since Sun picked up the Xylogic disk and tape control= lers that they developed 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 proliferation of different disk manufacturers -- something t= o make the boot ROMs and OS's more independent was forced on the differ= ent systems providers if they were going to have any chance of being able t= o be flexible in the market/field.

= =C2=A0

Maybe you can help me fi= nd it?
I'= ;ll see=C2=A0what I can dig up.
=C2=A0

= 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 th= e MK0, CSRG, and Sun connection via Fred, Bill, and Sam.=C2=A0 At a minimum= , they knew what the other was doing/had done, and some of it definitely mi= grated.

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, duri= ng the "JAWS" timeframe.=C2=A0 I am pretty sure that there were v= ersions 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
=
= 3D""=E1=90=A7
3D""=E1=90=A7 --000000000000ef3d3f060de47b8d--