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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28469 invoked from network); 15 Jul 2022 08:09:47 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 15 Jul 2022 08:09:47 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id B31F6406DF; Fri, 15 Jul 2022 18:09:10 +1000 (AEST) Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by minnie.tuhs.org (Postfix) with ESMTPS id 680F6406DE for ; Fri, 15 Jul 2022 18:09:04 +1000 (AEST) Received: by mail-wr1-f52.google.com with SMTP id f2so5681784wrr.6 for ; Fri, 15 Jul 2022 01:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pkJVWejvBKjH1MHetujAaQfSNazJhraM6qF9yAnlH/g=; b=XJsMWj3z/simpkzfdfi5EtU6WR6+Zf7V5KfhdfNjjDMhx3v777SxClSiXMLw6J27Ln HZzblJW/VLGkEjQEvTpCOmUxzOlrDaXiSAQiOKDHIjdctxg4faQvvUk8cWHX3jTkf64d GzMvf4q0nPuxoFBLcStI9m/TNrNI5PDO03X74rEr9lSh8d6N9ySTHVOvtrSzT3w9aRT3 t6J8TgJl1EijNG0Inir6iEQsVWzDAi2lHWNx62mWW699Sl6UA4veiYQNrrH0faBuxran JhJh9gPEy1iU+u9zUcF1gOvdfaohnIYONInhshL5sjDOESLnm6b2YP/xol2vqQxwCJ5X Dr/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pkJVWejvBKjH1MHetujAaQfSNazJhraM6qF9yAnlH/g=; b=3K55h7e87S6Lh2+EsI0FTkKRj0zxjUS2SCA5PepncOnLTs4Tqp14fEzOWmqv+jVcwu D8WPWqaH9DEFNELPQnZEAD71VaWczH5k291hJNDm9rl8JxWNxdYXchsgKgGmXm3zVUNY 4h2OyXemPpQ+/+bd49+YmPypHqut0CP38lJyyczleIuZJtP0Vgtk5nqYg+6WoUfpwrxM OXGErTsDJlKuOYwhLyyJnGP45ErcxQdYwuyh4ksw/ACZUQm2s6+dbCeHfg4AZ37xdltT aitwhDaemq9v6gspHERgcV+1V6IAq6tTNRuuGGOQJv+PE9I0HFwL++x8x8iUVlbuAX9F hHAQ== X-Gm-Message-State: AJIora/aWDy8TrSQEez5rFifUGlsi0xHxj3I9GWx5v1Z1qhF9luiEgvX ndhg0XXziqdiAMB+lCzVESxKv4m1ODAIOVnCOro= X-Google-Smtp-Source: AGRyM1uoTTfleyA1iH5C3Dsxn5LhadAM0Mv3TCfMkTMNkglOoL7jkFTXR0LMYkpGzcRABVMzUljkfSjH2vpus9IMbL8= X-Received: by 2002:adf:d20e:0:b0:21d:7654:729b with SMTP id j14-20020adfd20e000000b0021d7654729bmr11645891wrh.239.1657872482757; Fri, 15 Jul 2022 01:08:02 -0700 (PDT) MIME-Version: 1.0 References: <20220711234729.2E9F418C096@mercury.lcs.mit.edu> In-Reply-To: <20220711234729.2E9F418C096@mercury.lcs.mit.edu> From: Gavin Tersteeg Date: Fri, 15 Jul 2022 03:07:58 -0500 Message-ID: To: Noel Chiappa Content-Type: multipart/alternative; boundary="0000000000006aef7c05e3d3840b" Message-ID-Hash: IHM4YX5F7VPMSXPYFOEBHW3AYW27WD26 X-Message-ID-Hash: IHM4YX5F7VPMSXPYFOEBHW3AYW27WD26 X-MailFrom: gctersteeg@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: LSX issues and musing List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000006aef7c05e3d3840b Content-Type: text/plain; charset="UTF-8" Well, I have spent a few more days tentatively messing around with LSX, and I have noticed a few things. First off, the C compiler is not the only program to have occasional issues. Sometimes the "mv" command also fails with the oh-so-descriptive "?" error. By the looks of it, this error is caused by something going wrong with a fork() and subsequent wait() syscall. That recurring error in the C compiler is also caused by the 2nd pass of the C compiler not being able to find a temporary file created by the 1st pass. If the 1st pass was failing to run, then that would explain why the 2nd pass isn't able to find that temporary file. This has me guessing that there may be something wrong with fork() or exec(). Whenever it is, it doesn't dumpster memory or blow up the filesystem. For all I know, it may be an emulation issue too, but I have no way of testing it right now. The current kernel I am building is under 16KB at the moment. My goal is to be able to recreate the stock (semi?) functional kernel, and then do modifications from there. This goal has not been reached, as this kernel simply crashes on startup. It is either a HALT instruction or a stack issue depending on if the kernel has been stripped or not. I bet I am building it wrong again :/, it doesn't need to be reloc'd after the "ld -X" does it? Has anyone actually been able to get a system to build with the archived LSX disks? I have poured over the config files many times, but I feel like I am missing something painfully obvious... On Mon, Jul 11, 2022 at 6:47 PM Noel Chiappa wrote: > > From: Paul Ruizendaal > > > Note that LSX only holds one process in core and swaps other > processes > > (NPROC = 3) out to floppy. It reportedly took several hours for the > > Terak to self-compile LSX from source. > > If one is working in a simulator, and not a real hardware PDP-11, there's a > 'trick' one can use to make life a lot easier - for MINI-UNIX, at least; > I'll > comment on LSX below. > > As I report in the MINI-UNIX Computer History Wiki article: "MINI-UNIX uses > the same file system as V6; this allows MINI-UNIX packs to be 'mounted' on > V6 > systems (either real, or simulated), which is very convenient for working > on > them." So just spin up a V6 in the simulator, mount the LSX/MINI-UNIX pack, > and away you go. The V6 toolchain can be used to compile/link kernels; to > link user commands one will need to import the LSX/MINI-UNIX loader (which, > since V6 is source compatible with LSX/MINI-UNIX, is trivial). > > LSX is potentially more complex, as it supports _two different_ file system > formats: the standard V6 one, and a 'contiguous' one which is very similar > to the V6 one (rdwri.c has no conditionals on CONTIG; not so alloc.c, > though), but is not fully compatible. So non-contiguous LSX file systems > can be mounted under V6, but not contiguous ones. > > Noel > --0000000000006aef7c05e3d3840b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, I have spent a few more days=C2=A0tentatively messin= g around with LSX, and I have noticed a few things.

Firs= t off, the C compiler is not the only program to have occasional issues. So= metimes the "mv" command also fails with the oh-so-descriptive=C2= =A0"?" error. By the looks of it, this error is caused by somethi= ng going wrong with a fork() and subsequent wait() syscall. That recurring = error in the C compiler is also caused by the 2nd pass of the C compiler no= t being able to find a temporary file created by the=C2=A01st pass. If the = 1st pass was failing to run, then that would explain why the 2nd pass isn&#= 39;t able to find=C2=A0that temporary file. This has me guessing that there= may be something wrong with fork() or exec(). Whenever it is, it doesn'= ;t dumpster memory or blow up the filesystem. For all I know, it may be an = emulation issue too, but I have no way of testing it right now.

The current kernel I am building is under 16KB at the mome= nt. My goal is to be able to recreate the stock (semi?) functional kernel, = and then do modifications from there. This goal has not been reached, as th= is kernel simply crashes on startup. It is either a HALT instruction or a s= tack issue depending on if the kernel has been stripped or not. I bet I am = building it wrong again :/, it doesn't need to be reloc'd after the= "ld -X" does it?

Has anyone actually be= en able to get a system to build with the archived LSX disks? I have poured= over the config files many times, but I feel like I am missing something p= ainfully=C2=A0obvious...

On Mon, Jul 11, 2022 at 6:47 PM N= oel Chiappa <jnc@mercury.lcs.= mit.edu> wrote:
=C2=A0 =C2=A0 > From: Paul Ruizendaal

=C2=A0 =C2=A0 > Note that LSX only holds one process in core and swaps o= ther processes
=C2=A0 =C2=A0 > (NPROC =3D 3) out to floppy. It reportedly took several = hours for the
=C2=A0 =C2=A0 > Terak to self-compile LSX from source.

If one is working in a simulator, and not a real hardware PDP-11, there'= ;s a
'trick' one can use to make life a lot easier - for MINI-UNIX, at l= east; I'll
comment on LSX below.

As I report in the MINI-UNIX Computer History Wiki article: "MINI-UNIX= uses
the same file system as V6; this allows MINI-UNIX packs to be 'mounted&= #39; on V6
systems (either real, or simulated), which is very convenient for working o= n
them." So just spin up a V6 in the simulator, mount the LSX/MINI-UNIX = pack,
and away you go. The V6 toolchain can be used to compile/link kernels; to link user commands one will need to import the LSX/MINI-UNIX loader (which,=
since V6 is source compatible with LSX/MINI-UNIX, is trivial).

LSX is potentially more complex, as it supports _two different_ file system=
formats: the standard V6 one, and a 'contiguous' one which is very = similar
to the V6 one (rdwri.c has no conditionals on CONTIG; not so alloc.c,
though), but is not fully compatible. So non-contiguous LSX file systems can be mounted under V6, but not contiguous ones.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Noel
--0000000000006aef7c05e3d3840b--