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 3037 invoked from network); 3 Aug 2023 21:24:46 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 3 Aug 2023 21:24:46 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id AD60741680; Fri, 4 Aug 2023 07:24:42 +1000 (AEST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by minnie.tuhs.org (Postfix) with ESMTPS id 708D54167C for ; Fri, 4 Aug 2023 07:24:35 +1000 (AEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 8EA3132009F8; Thu, 3 Aug 2023 17:24:34 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 03 Aug 2023 17:24:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ronnatalie.com; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:sender:subject:subject:to:to; s=fm2; t= 1691097874; x=1691184274; bh=O/4yPbcaCUHKgE4FFbYwHLF8VYi1dEL6Nbh goYGDyJs=; b=w/m1TzO2H0abqwpjBWP6P8CoBIAbwLvxjyd4crREygB2Q7Yxvqp LDhzzc3KhatcCeFQx+XgDuw9LjLioD2kjIU0VbFdwAkEblVf737NVyg3EVr+nrWO Uxu+7kAL4vUn5rPd+BJw0C6a2lYjp0swn1AldPAXEMLzeRgtRYBC8nqN4ayljkPY FhYze0ciY4vjLDD2X6Ta+w5+Qv4wrzdhrrTaKazw1ZfBbD+/kQcNHTiMza+frSnI 1qdxGchdkIhkkWcM1hakkw5uqn3ovnzQYZRk2INIwK//IUSpupSrobkNbH/d70FQ dnEnLuwYsUlfL69lcNQWaZKNM7OH2I+SW4w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1691097874; x=1691184274; bh=O /4yPbcaCUHKgE4FFbYwHLF8VYi1dEL6NbhgoYGDyJs=; b=hSm0hqU3cCaW09B2G aQy0/GztvUp+CWffFKfJBhm2HfBKhI4kJcS7sRzYzOFGJgi68qUAHPsOPFyS9cdc K6bkKFn/08kweUAMuoafAiPIHJfebluXMAydmph1Q5n7qKvvHTv74NUg9/vSO7r8 vsd5Rb8ZpTtKZ6aO8hn6W1lgAoIPdri0QRiVWzVtE7OnamlppxxZC5C1JSM3QAMB g1TExqdXiHMfVvn2PJojLvKz0gFjNYsDyzFMrTmua8kt2k4oJxSztS+VE3vLMYHd mRfA426fRKL/CihZilKmvF7Rx+iZX8DvxHwNx1A7lKElzBvhTf3rMFbAyfK3A8ZP rB2Ew== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrkedvgdduheekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufevfffkjghfrhgfgggtsegrtderredtreejnecuhfhrohhmpedftfho nhgrlhguucfprghtrghlihgvfdcuoehrohhnsehrohhnnhgrthgrlhhivgdrtghomheqne cuggftrfgrthhtvghrnhepudekhfffieeikefghefhfeejfefhleduvddtffevleelkeeg leegtedvgfdtfeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomheprhhonhesrhhonhhnrghtrghlihgvrdgtohhm X-ME-Proxy: Feedback-ID: iaba146ad:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 3 Aug 2023 17:24:33 -0400 (EDT) From: "Ronald Natalie" To: "Warner Losh" Date: Thu, 03 Aug 2023 21:24:32 +0000 Message-Id: In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> User-Agent: eM_Client/9.2.1841.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB49D99BB4-51F8-4760-B15C-F0364FB4D40C" Message-ID-Hash: F4WASPWWBQSTNK6FMEIWKL2L6EI7BQMX X-Message-ID-Hash: F4WASPWWBQSTNK6FMEIWKL2L6EI7BQMX X-MailFrom: ron@ronnatalie.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: The Eunuchs Hysterical Society X-Mailman-Version: 3.3.6b1 Precedence: list Reply-To: Ronald Natalie Subject: [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread) List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --------=_MB49D99BB4-51F8-4760-B15C-F0364FB4D40C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable In fact, it was TCP (mbuf windowing) that killed the non split-I/D=20 systems in our installation. We were already using kernel overlays,=20 but with only 8 segment registers combined for code, data, and stack, we=20 just ran out of registers. By then the VAXEN were coming along. I=20 recycled the 11/34=E2=80=99s etc=E2=80=A6 into LOS/C Internet routers. The 55 (just a tweaked 45) and later the 44 also had it. In addition=20 the 23/24/J-11 and those derived processors did. ------ Original Message ------ >From "Warner Losh" To "Ronald Natalie" Cc "Kenneth Goodwin" ; "Will Senn"=20 ; "The Eunuchs Hysterical Society" Date 8/3/23, 5:16:25 PM Subject Re: [TUHS] Re: Split addressing (I/D) space (inspired by the=20 death of the python... thread) >2BSD also did split I&D in the kernel (as well as run TCP in supervisor=20 >mode to get another I/D space). A lot of the overlays was done in the=20 >linker, but it wasn't completely automated. >I had to tweak the overlay tables a little as I did the 2.11pl0 work=20 >since the early stuff wasn't exactly careful about distributing the=20 >hacks to the makefile to make it happen... > >Warner > >On Thu, Aug 3, 2023 at 3:10=E2=80=AFPM Ronald Natalie = =20 >wrote: >>Having cut my UNIX teeth on the JHU 11/45, I can tell you very much=20 >>that it did have split I/D. V6 supported split I/D for user mode=20 >>programs. The kernel originally wasn=E2=80=99t split I/D. Version 7,= if=20 >>I=E2=80=99m recalling properly, did run the kernel split I/D on the 45 an= d 70. >> >> >> >>------ Original Message ------ >>>From "Kenneth Goodwin" >>To "Will Senn" >>Cc "The Eunuchs Hysterical Society" >>Date 8/3/23, 5:05:31 PM >>Subject [TUHS] Re: Split addressing (I/D) space (inspired by the death=20 >>of the python... thread) >> >>>At the risk of exposing my ignorance and thus being events long long=20 >>>ago in history.... >>>And my mind now old and feeble... >>> >>>=F0=9F=98=86 =F0=9F=A4=A3 >>> >>>1. I don't think the 11/45 had split I & d. >>>But I could be wrong. >>>That did not appear until the 11/70 >>>And was in the later generation 11/44 several years later. >>> >>>2. The kernel determined it by MMU type and managed it solely. The=20 >>>assembler and loader always built the binary object file as the three=20 >>>sections - instructions, data and bss spaces so loading an object=20 >>>file could be done on any platform. >>>Programmers generally did not worry about the underlying hardware >>> >>>3. I don't recall if a systype style system call was available in v7=20 >>>to give you a machine type to switch off of. >>> >>>With something like that you could determine memory availability hard=20 >>>limits on the DATA/bss side if you needed to. >>> >>>But that was also easily determined by a allocation failure in=20 >>>malloc/sbrk with an out of memory error. >>> >>>If you really needed to know availability, you could have a start up=20 >>>subroutine that would loop trying to malloc ever decreasing memory=20 >>>sizes until success and until out of available memory error. >>>Then release it all back via free(). Or manage it internally. >>> >>>As I recall however vaguely, there was an attempt to split the=20 >>>kernel into two pieces. One running in kernel mode and one running in=20 >>>supervisor mode in order to double the amount of available =20 >>>instruction and data spaces for the operating system. I recall=20 >>>playing around with what was there trying to get it to work right. >>>I was trying to support over 200 users on a pdp 11/70 at the time=20 >>>running a massive insurance database system. >>> >>>On Thu, Aug 3, 2023, 4:35 PM Will Senn wrote: >>>>Does unix (v7) know about the PDP-11 45's split I/D space through >>>>configuration or is it convention and programmer's responsibility to >>>>know and manage what's actually available? >>>> >>>>Will >>>> >>>>On 8/3/23 12:00, Rich Salz wrote: >>>> > What, we all need something to kick now that we've beaten=20 >>>>sendmail? >>>> > How about something unix, ideally a decade old? >>>> --------=_MB49D99BB4-51F8-4760-B15C-F0364FB4D40C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div>In fact, it was TCP (mbuf windowing) that killed the non split-I/D syst= ems in our installation. =C2=A0 =C2=A0We were already using kernel overlays= , but with only 8 segment registers combined for code, data, and stack, we= just ran out of registers. =C2=A0 =C2=A0 By then the VAXEN were coming alon= g. =C2=A0I recycled the 11/34=E2=80=99s etc=E2=80=A6 into LOS/C Internet ro= uters. =C2=A0=C2=A0

The 55 (just a tweaked 45) a= nd later the 44 also had it. =C2=A0 In addition the 23/24/J-11 and those de= rived processors did.
=0A

=0A
=0A
=0A
------ Original Message ------
=0A
Fr= om "Warner Losh" <imp@bsdimp.com&g= t;
=0A
To "Ronald Natalie" <ron@ronnatalie.com>
=0A=0A
Date 8/3/23, 5:16:25 PM
=0ASubject Re: [TUHS] Re: Split addressing (I/D) space (inspired by the death = of the python... thread)

=0A
=0A
2BSD also did split I&D in the kernel (as well as run TCP in supervis= or mode to get another I/D space). A lot of the overlays was done in the li= nker, but it wasn't completely automated.
I had to tweak the overlay ta= bles a little as I did the 2.11pl0 work since the early stuff wasn't exactl= y careful about distributing the hacks to the makefile to make it happen...=

Warner

On Thu, Aug 3, 2023 at 3:10=E2=80= =AFPM Ronald Natalie <ron@ronnatal= ie.com> wrote:
Having cut my UNIX = teeth on the JHU 11/45, I can tell you very much that it did have split I/= D. =C2=A0 =C2=A0V6 supported split I/D for user mode programs. =C2=A0 The k= ernel originally wasn=E2=80=99t split I/D. =C2=A0 Version 7, if I=E2=80=99m = recalling properly, did run the kernel split I/D on the 45 and 70.

=0A

=0A

=0A
=0A
------ Original Message ------
=0A
From "Kenneth= Goodwin" <kennethgoodwin56= @gmail.com>
=0A
To "Will Senn" <will.senn@gmail.com>
=0A
Cc "The Eunuchs Hys= terical Society" <tuhs@tuhs.org>=
=0A
Date 8/3/23, 5:05:31 PM
=0A
Subject [TUHS] Re: Split = addressing (I/D) space (inspired by the death of the python... thread)

=0A
=0A
At the risk of exposing my ignorance and thus b= eing events long long ago in history....
And my mind now o= ld and feeble...

=F0= =9F=98=86 =F0=9F=A4=A3=C2=A0

1.=C2=A0 I don't think the 11/45 had split I & d.
But I could be wrong.
That did not appear= until the 11/70
And was in the later generation 11/4= 4 several years later.

2. The kernel determined it by MMU type and managed it solely. The assembl= er and loader always built the binary object file as the three sections - i= nstructions,=C2=A0 data and bss spaces so loading an object file could be d= one on any platform.
Programmers generally did not w= orry about the underlying hardware=C2=A0

3. I don't recall if a systype style system call was ava= ilable in v7 to give you a machine type to switch off of.

With something like that you could dete= rmine memory availability hard limits on the DATA/bss side if you needed to= .

But that was also ea= sily determined by a allocation failure in malloc/sbrk with an out of memor= y error.

If you really = needed to know availability,=C2=A0 you could have a start up subroutine th= at would loop trying to malloc ever decreasing memory sizes until success a= nd until out of available memory error.
Then release = it all back via free(). Or manage it internally.
As I recall however vaguely,=C2=A0 there was an = attempt to split the kernel into two pieces. One running in kernel mode an= d one running in supervisor mode in order to double the amount of available= =C2=A0 instruction and data spaces for the operating system. I recall playi= ng around with what was there trying to get it to work right.
I was trying to support over 200 users on a pdp 11/70 at the time = running a massive insurance database system.

On Thu, Aug 3, 2= 023, 4:35 PM Will Senn <will.senn@gmail.com> wrote:
Does unix (v7) know about the PDP-11 45's= split I/D space through
=0Aconfiguration or is it convention and prog= rammer's responsibility to
=0Aknow and manage what's actually availab= le?
=0A
=0AWill
=0A
=0AOn 8/3/23 12:00, Rich Salz wrote= :
=0A> What, we all need something to kick now that we've beaten se= ndmail?=C2=A0
=0A> How about something unix, ideally a decade old?=
=0A
=0A
=0A
=0A
<= /blockquote>
=0A
=0A --------=_MB49D99BB4-51F8-4760-B15C-F0364FB4D40C--