The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Heinz Lycklama <>
Subject: [TUHS] Re: LSX issues and musing
Date: Sun, 31 Jul 2022 22:37:35 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Remember that the LSX and Mini-UNIX systems were
developed for two different purposes.
     1. LSX had limited resources available to it and thus
         some general-purpose features had to be removed.
         LSX supported some new features for the support
         of real-time systems and intelligent terminals. The
         features included contiguous files and asynchronous
         read/write capabilities.
     2. Mini-UNIX was developed to run on PDP11/10 computers
         without memory management support at the hardware level.
         Larger main memory and faster larger disks were available.
         It was designed to support up to four users at a time, and
         thus needed to support the latest UNIX System features
         without the additional features available on LSX.

To answer the question below about kernel code to create
contiguous - the only change in the kernel code was to
recognize a contiguous file in the inode. The actual file
had to be created by a system program to keep the
kernel as small as possible.


On 7/31/2022 12:57 PM, Noel Chiappa wrote:
> {I was going to reply to an earlier message, but my CFS left me with
> insufficient energy; I'll try and catch up on the points I was goibf to make
> here.}
>      > From: Gavin Tersteeg
>      > This leaves me with about 1.9kb of space left in the kernel for
>      > additional drivers
> I'm curious how much memory you have in your target system; it must not be a
> lot, if you're targeting LSX.
> I ask because LSX has been somewhat 'lobotimized' (I don't mean that in a
> negative way; it's just recognition that LSX has had a lot of corners
> trimmed, to squeeze it down as much as possible), and some of those trims
> behind some of the issues you're having (below).
> At the time the LSI-11 came out, semiconductor DRAM was just getting started,
> so an LSI-11 with 8KB onboard and a 32KB DRAM card (or four 8KB MMV11 core
> memory cards :-), to produce the 40KB target for LSX systems, was then a
> reasonable configuration. These days, one has to really search to find
> anything smaller than 64KB...
> It might be easier to just run MINI-UNIX (which is much closer to V6, and
> thus a known quantity), than add a lot of things back in to LSX to produce
> what will effectively be MINI-UNIX; even if you have to buy a bit more QBUS
> memory for the machine.
>      > the LSX "mkfs" was hardcoded to create filesystems with 6 blocks of
>      > inodes. This maxed the number of files on a disk to 96, but even with
>      > the maximum circumvented LSX would only tolerate a maximum of 101 files.
> And here you're seeing the 'lobotomizing' of LSX come into play. That '101'
> made me suspicious, as the base V6 'caches' 100 free inodes in the
> super-block; once those are used, it scans the ilist on disk to refill it.
> The code in alloc$ialloc in LSX is hard to understand (there are a lot of
> #ifdef's), and it's very different from the V6 code, but I'm pretty sure it
> doesn't refill the 'cache' after it uses the cached 100 free inodes. So, you
> can have as many free inodes on a disk as you want, but LSX will never use
> more than the first 100.
> (Note that the comment in the LSX source "up to 100 spare I nodes in the
> super block. When this runs out, a linear search through the I list is
> instituted to pick up 100 more." is inaccurate; it probably wasn't updated
> after the code was changed. ISTR tis is true of a lot of the comments.)
>     > A fresh filesystem that was mkfs'd on stock V6 can be mounted on LSX,
>     > but any attempt to create files on it will fail.
> The V6 'mkfs' does not fill the free inode cache in the super-block. So, it's
> empty when you start out. The LSX ialloc() says:
> 	if(fp->s_ninode > 0) {
> 	...
> 	}
> 	u.u_error = ENOSPC;
> 	return(NULL);
> which would produce what you're seeing.
> Also, another problem with trying to 'push' LSX into a previously un-handled
> operating regions (e.g. large disks, but there are likely others) is that
> there are probably things that are un-tested in that previously unused
> operating mode, and there may be un-found bugs that you trip across.
>      > Interestingly enough, existing large V6 RK05 images can be mounted,
>      > read from, and written to. The only limitations on these pre existing
>      > images is that if enough files are deleted, the system will randomly crash.
> I had a look at the source (in sys4.c, nami.c, iget.c, rdwri.c, and alloc.c),
> but I couldn't quickly find the cause; it isn't obvious. (When unlinking a
> file, the blocks in the file have to be freed - that's inode 'ip' - and the
> directory - inode 'pp' - has to be updated; so it's pretty complicated.)
>     > The information there about continuous files ... will be extremely
>     > helpful if I ever try to make those work in the future.
> My recollection is that the LSX kernel doesn't have code to create contiguous
> files; the LSX page at the CHWiki says "the paper describing LSX indicates
> there were two separate programs, one to allocate space for such files, and
> one to move a file into such an area, but they do not seem to be extant". If
> you find them, could you let me know? Thanks.
> 	Noel

  reply	other threads:[~2022-08-01  5:38 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-31 19:57 Noel Chiappa
2022-08-01  5:37 ` Heinz Lycklama [this message]
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
  -- 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-11 23:47 Noel Chiappa
2022-07-15  8:07 ` Gavin Tersteeg
2022-07-27  8:02   ` Gavin Tersteeg
2022-07-27 16:24     ` Heinz Lycklama
2022-07-30  4:39       ` Gavin Tersteeg
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:

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

  git send-email \ \ \ \ \ \

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