The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Gavin Tersteeg <gctersteeg@gmail.com>
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Cc: tuhs@tuhs.org
Subject: [TUHS] Re: LSX issues and musing
Date: Fri, 15 Jul 2022 03:07:58 -0500	[thread overview]
Message-ID: <CA+99DoJEUJRv6EMfGQs7QLouE798b=LY4XmdtEJzKXWNyZdSNw@mail.gmail.com> (raw)
In-Reply-To: <20220711234729.2E9F418C096@mercury.lcs.mit.edu>

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

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 <jnc@mercury.lcs.mit.edu>
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
>

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

  reply	other threads:[~2022-07-15  8:09 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-11 23:47 Noel Chiappa
2022-07-15  8:07 ` Gavin Tersteeg [this message]
2022-07-27  8:02   ` Gavin Tersteeg
2022-07-27 16:24     ` Heinz Lycklama
2022-07-30  4:39       ` Gavin Tersteeg
  -- strict thread matches above, loose matches on Subject: below --
2022-08-05  4:35 Paul Ruizendaal via TUHS
2022-08-03 15:17 Noel Chiappa
2022-07-31 19:57 Noel Chiappa
2022-08-01  5:37 ` Heinz Lycklama
2022-08-02 17:56   ` Gavin Tersteeg
2022-08-03  4:32     ` steve jenkin
2022-08-03  4:55       ` Ron Natalie
2022-08-03  5:09       ` G. Branden Robinson
2022-07-11 21:47 Paul Ruizendaal via TUHS
2022-07-11 21:24 Noel Chiappa
2022-07-11 21:37 ` Gavin Tersteeg
2022-07-11 21:06 Noel Chiappa
2022-07-11 19:47 [TUHS] " Gavin Tersteeg
2022-07-11 20:01 ` [TUHS] " Warner Losh
2022-07-11 20:26   ` Clem Cole
2022-07-11 20:30     ` Warner Losh
2022-07-11 20:37 ` Phil Budne

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='CA+99DoJEUJRv6EMfGQs7QLouE798b=LY4XmdtEJzKXWNyZdSNw@mail.gmail.com' \
    --to=gctersteeg@gmail.com \
    --cc=jnc@mercury.lcs.mit.edu \
    --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).