The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Clem Cole <clemc@ccc.com>
To: Warner Losh <imp@bsdimp.com>
Cc: Grant Taylor <gtaylor@tnetconsulting.net>,
	The Unix Heritage Society <tuhs@tuhs.org>
Subject: [TUHS] Re: Question about BSD disklabel history
Date: Mon, 1 Jan 2024 11:00:07 -0500	[thread overview]
Message-ID: <CAC20D2OOCOXA+SpE=shmCnnJnxZLG8gmuDHp8Sp8SZmO7invvQ@mail.gmail.com> (raw)
In-Reply-To: <CANCZdfr2HNXMGvx2riSdWxj_M25Tf=66TwtaBFYpeKBei09VEg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4496 bytes --]

Warner -- thanks...

On Sun, Dec 31, 2023 at 5:07 PM 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 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) 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).






> 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 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.

ᐧ
ᐧ

[-- Attachment #2: Type: text/html, Size: 8835 bytes --]

  reply	other threads:[~2024-01-01 16:01 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-31 17:30 [TUHS] " Grant Taylor via TUHS
2023-12-31 17:38 ` [TUHS] " arnold
2023-12-31 20:07   ` Warner Losh
2024-01-01  0:13     ` Bakul Shah
2023-12-31 20:27   ` Phil Budne
2023-12-31 21:02     ` Warner Losh
2024-01-01  0:26   ` Grant Taylor via TUHS
2024-01-01  2:22     ` Warner Losh
2024-01-01  3:24       ` Grant Taylor via TUHS
2023-12-31 21:31 ` Clem Cole
2023-12-31 22:07   ` Warner Losh
2024-01-01 16:00     ` Clem Cole [this message]
2024-01-02 18:49       ` Warner Losh
2024-01-02 19:30         ` Chet Ramey
2024-01-02 20:07           ` Clem Cole
2024-01-02 19:50         ` Dan Cross
2024-01-02 19:55           ` Jim Capp
2024-01-02 20:11             ` Dan Cross
2024-01-02 20:30           ` Dan Cross
2024-01-02 20:50             ` Clem Cole
2024-01-02 21:04               ` Dan Cross
2023-12-31 22:46   ` G. Branden Robinson
2023-12-31 23:06     ` Larry McVoy
2023-12-31 23:37       ` Al Kossow
2023-12-31 23:41       ` Alec Muffett
2024-01-02 20:48       ` Dan Cross
2024-01-02 21:17         ` John Cowan
2024-01-03  3:33         ` Theodore Ts'o
2024-01-03  3:57           ` Warner Losh
2024-01-03  4:03             ` Warner Losh
2024-01-03  4:30             ` Theodore Ts'o
2024-01-03  5:10               ` Warner Losh
2024-01-03 15:56                 ` Dan Cross
2024-01-03 16:37                   ` Theodore Ts'o
2024-01-03 16:41                     ` Dan Cross
2024-01-04  8:42                     ` arnold
2024-01-04 18:26                       ` Kevin Bowling
2024-01-03 14:39           ` Dan Cross
2023-12-31 23:08     ` Phil Budne
2023-12-31 23:37       ` G. Branden Robinson
2023-12-31 23:59         ` Warner Losh
2023-12-31 23:50     ` G. Branden Robinson
2024-01-01  0:09       ` Al Kossow
2023-12-31 21:55 Norman Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAC20D2OOCOXA+SpE=shmCnnJnxZLG8gmuDHp8Sp8SZmO7invvQ@mail.gmail.com' \
    --to=clemc@ccc.com \
    --cc=gtaylor@tnetconsulting.net \
    --cc=imp@bsdimp.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).