[HN Gopher] Why V7 Unix matters so much
___________________________________________________________________
Why V7 Unix matters so much
Author : zdw
Score : 143 points
Date : 2021-11-22 16:32 UTC (4 days ago)
(HTM) web link (utcc.utoronto.ca)
(TXT) w3m dump (utcc.utoronto.ca)
| cturner wrote:
| I feel the same - V7 is significant - but for different reasons.
|
| (1) V7 did not use a MMU, there are no shared object libraries.
| The whole stack feels simpler, less layered. It is
| straightforward to hand-craft a binary on a pre-ELF system.
|
| (2) V7 was just before select was introduced. V7 was only capable
| of basic networking like uucp where you give over the cpu to the
| networking operation.
|
| A while back I wrote some notes contrasting RetroBSD (2BSD, close
| to v7) to LiteBSD (4.4 BSD),
| http://songseed.org/dinghy/d.pic32.platform.html
|
| Both ports were done by the same developer, from different
| versions of the same codebase, separated by four years. If you
| compared any releases of Solaris, FreeBSD and Linux from the last
| twenty years, the differences would seem trivial compared to the
| differences between RetroBSD and LiteBSD.
| whartung wrote:
| If V7 didn't use an MMU, how did it load programs? Did it rely
| on PIC code? Did it have a relocating loader that it relied
| upon? Curious how Unix managed to progress as far and as
| quickly as it did without an MMU while relying on something as
| notorious as C in an unprotected space. Just seems system
| stability would always be at stake.
|
| Just curious what their experiences were like, not questioning
| it.
| phicoh wrote:
| The pdp-11 had a very primitive virtual memory system. It was
| not page based. So you had to swap in and out entire
| processes (with seperate instruction and data you could leave
| the program in memory, swap out data, and swap in data from
| another process running the same program).
|
| Later pdp-11 models could have a few processes in ram at the
| same time.
| monocasa wrote:
| Only for very low end systems. Most PDP-11s running Unix
| had something like the KT-11D MMU providing true paging
| hardware.
| phicoh wrote:
| You are right. After I wrote my text, I realised that
| there must have been some kind of paging. Of course, with
| 8 Kbyte pages in a 64 Kbytes it is not the same
| granularity as today. Imagine unmapping one page to keep
| the stack separate from the heap. That's 1/8th of your
| already small address space.
|
| But the part that is also missing the ability to restart
| instructions after a page fault. If I remember correctly
| some old discussion, that may have been possible for many
| instructions but not some popular instructions.
|
| I found an online copy of the reference manual which
| states: "It is not generally possible to recover from
| these aborts."
|
| So paging yes, but not in the modern sense where you can
| recover from a page fault. Which is key to many aspects
| of a modern unix system. For example, copy-on-write
| forks.
| monocasa wrote:
| The 8KB pages could also be broken down into 128 byte
| blocks, so that you could map a (contiguous) portion of a
| page, and not have to use the whole 8KB. You could also
| use the same feature to give yourself guard 'pages' (but
| really guard blocks). It specifically supported the
| ability to grow down for stacks and guards.
|
| And the abort issue is around restarting indirect
| addressing modes, which will result in repeats of
| accesses. Technically this is an issue if you were
| pulling pointers directly out of MMIO regions, but it's
| one of those "doctor it hurts when I do this." "Then
| don't do that" kind of situation. If you're getting real
| cute with advanced addressing using MMIO regions to
| bounce out to other regions, do that in the kernel (as
| you probably would be anyway). Then you can do all the
| fun virtual memory tricks.
| monocasa wrote:
| V7 absolutely used the MMU. V6 did too; you can see it's use
| in Lyon's commentary.
| adrian_b wrote:
| The PDP-11 had a MMU, but it was an extremely simple MMU,
| even simpler than what was available in Intel 8088/8086.
|
| When MMU is mentioned in UNIX context, a MMU like in DEC
| VAX is understood, which provided features like access
| protection, dynamic relocation and virtual memory.
|
| The main purpose of the PDP-11 MMU was to extend the
| maximum memory size from 64 kB to 4 MB, but that was done
| in a very inconvenient way.
|
| A single process was limited to 64 kB of program code + 64
| kB of data. For larger processes one had to use memory
| overlays, i.e. to swap out parts of the program while other
| parts were swapped in over the same addresses, but this
| feature was not used in UNIX, but in other operating
| systems for PDP-11, e.g. DEC RSX-11M.
|
| In UNIX, the larger memory was exploited by loading in
| memory many concurrent processes. It was easier to split
| some task into subtasks done by cooperating processes
| communicating through pipes, than to attempt to remap some
| of the 8 kB pages of the 64 kB address space while the
| program was running, in order to exceed the process size
| limit.
| monocasa wrote:
| The PDP-11 MMU was more powerful than what existed in the
| 8088/8086. It provided a supervisor/user distinction and
| didn't allow user code to go to town on the MMU directly.
| Yes, being a true 16 bit system, it was limited to 64KB
| total in each address space, but there was both
|
| * True process isolation since user code couldn't load
| whatever they wanted into the base registers like on an
| 8086,
|
| * True pages, so that the entire 64KB didn't have to be
| contiguous like on a 8086, but was instead broken into
| 8KB pages that could be mapped, shared between process,
| and mixed together in different places in the virtual
| address space.
|
| Everything you're saying applies equally to the 32bit
| virt/36bit phys PAE world that we had for a while, and I
| wouldn't call that a simple MMU.
| adrian_b wrote:
| It is true that the PDP-11 MMU provided memory
| protection, unlike 8088/8086.
|
| However that mattered only for the operating system
| kernel, as it allowed process isolation.
|
| For user programs, the 8088/8086 MMU was a thousand times
| more convenient, because the segments could start on any
| 16-byte boundary instead of 8 kB boundaries and there
| were 4 segments instead of 2 and you could load a pointer
| to a new segment with a single instruction.
|
| For an IBM PC, it was very easy to write a 512 kB
| program, you just had to select an appropriate memory
| model option for the compiler. For a PDP-11, even when
| having 4 MB of memory, writing a large program was
| extremely difficult.
|
| You had to partition the code and data of the program in
| pieces not to small and not too large, to fit in 1 or a
| few 8 kB pages. You had to partition in such a way that
| the parts will not need to be active simultaneously and
| you would not need to swap them frequently. Swapping
| parts was slow, as it had to be done by an operating
| system call.
|
| The linker had to be instructed to allocate the
| overlapping parts to appropriate addresses, so that it
| will be possible to swap them.
| monocasa wrote:
| If you wanted to escew protection for ease of use, you
| could just map the unibus page into the user process and
| let them fiddle the attributes directly.
|
| Additionally the 8kb pages were subdivided into 128B
| contiguous blocks, with a base and limit, allowing
| smaller granularity.
|
| The feature set that the 8086 gave you was more or less
| still available, there was just another option that was
| deemed more useful in most cases.
| danachow wrote:
| The 8088/8086 did not have an MMU.
| adrian_b wrote:
| The 8088/8086 had a MMU that provided only addressing
| space extension, from 16-bit to 20-bit.
|
| It did not provide memory protection.
|
| The PDP-11 MMU provided memory protection so that process
| isolation was possible, but its main function was also
| addressing space extension, from 16-bit to 18-bit in the
| first version and from 16-bit to 22-bit in the later
| version, but that function was much less convenient to
| use than in 8088/8086.
| denotational wrote:
| I don't have any knowledge of V7, but V6 definitely used an
| MMU (as does xv6).
| CalChris wrote:
| V7 supported hardware segmentation registers. Look at _sureg()_
| in _usr /sys/sys/ureg.c_ [1]. What it didn't support was pages.
| That came with 3BSD [2].
|
| [1] https://github.com/v7unix/v7unix/blob/master/v7.tar.gz
|
| [2]
| https://en.wikipedia.org/wiki/History_of_the_Berkeley_Softwa...
|
| BTW, I think by far the main reason that V7 matters is that it
| was (somewhat) portable. That begat the workstation boom.
| monocasa wrote:
| They call them segmentation registers in the source, but it's
| really paging hardware in the modern parlance. The estabur
| function in your citation can be seen iterating over the
| whole virtual address spaces (one each for I and D), and
| setting the permissions for each 8KB page. It's not super
| clearly written code, but those ap and dp variables are
| pointers to PTEs.
|
| The hardware they're programming against is a KT-11D
| (compatible) MMU. Here's it's user guide: http://www.bitsaver
| s.org/pdf/dec/pdp11/1140/KT11D_UsersMan.p...
| retrac wrote:
| Its popularity and persistence was partly because of its size.
| Each release got a lot bigger. A v6 system fits easily into 128
| KB of RAM and there are stripped down ports that run in less. v7
| is just a little bigger. Small and comprehensible. See:
| https://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6t...
|
| V7 also persisted well into the 80s because it was a lot easier
| to port. And again the size meant it could fit on small machines.
| In 1983, the year the IBM PC XT with a hard drive came out,
| commercial AT&T UNIX was up to System V which was _enormous_. It
| wouldn 't have fit in the RAM or disk of the XT.
| dboreham wrote:
| V7 user 1978-1981 here. Reason #1 in the article is surely the
| main one -- it's the common evolutionary ancestor for the
| mainstream computing platform we use today.
|
| I think V7 also played a part in establishing the OSS environment
| we're used to today. It was the first major production OS for
| which the source was freely available, at least until lawyers put
| an end to that. I think this produced a generation of programmers
| who had enjoyed that experience and hence worked to bring it
| back.
| ChuckMcM wrote:
| Also one "follow-on" to V7 was plan9 (also from CSRC). So in many
| ways looking to Plan9 to see how "the forefathers of UNIX" would
| improve something can be instructive as well.
| p_l wrote:
| There was V8, V9 and V10 in between, with V8 using BSD as base,
| iirc, but creating streams and TLI/XTI instead of BSD Sockets
| (XTI was superior API, tbqh)
| eminence32 wrote:
| V7 was released in 1979. If you click on the first link in the
| article, you get to the wikipedia page on V7, and from there you
| have a screenshot[1] of what running `ls -l /usr` looked like in
| a terminal
|
| Two things stand out to me about this screenshot:
|
| 1. The output of `ls -l` is very very similar to what my 2021
| debian+coreutils produces.
|
| 2. The contents of `/usr` are not all that different either!
| Directories that are common to my system and this screenshot are:
| games, include, lib, src.
|
| [1]
| https://en.wikipedia.org/wiki/Version_7_Unix#/media/File:Ver...
| adrian_b wrote:
| UNIX V7 (1979) had more differences compared to the older
| versions than all the current UNIX descendants have compared to
| V7.
|
| The POSIX standards correspond mostly with V7 with relatively
| minor additions from the later ATT and BSD UNIX versions.
|
| Many of the command line utilities that are still used today
| have appeared only in V7, e.g. the Bourne shell sh, sed, awk,
| m4, lex, basename, test, expr.
|
| Most command line utilities from V6 or older versions, even
| those that have the same name as later utilities, may have very
| different behavior.
| simonblack wrote:
| I came to UNIX via a v7 clone, Mark Williams' Coherent, back in
| 1991. I have used UNIX and UNIX-like OSs (Linux after 2001) as my
| everyday system ever since.
|
| After discovering how primitive the much-vaunted Windows 3.1 was,
| back in the early 1990s, I never went through a 'Windows as my
| everyday OS' phase at all.
| pjmlp wrote:
| For CLI stuff yes, for those of us into gaming and graphics,
| only the likes of SGI and NeXT were appealing, and they were
| quite out of reach.
|
| I had a big UNIX phase, and ironically my graduation thesis was
| to port an Objective-C based particle engine framework into
| MFC, as the department was getting rid of their NeXTSTEP Cube,
| and the department was going into Windows for graphics
| programming.
|
| Additionally the library archives of the faculty showed me the
| alternative computing universes and thus UNIX lost its magic to
| me.
| ggm wrote:
| I was shown it in 79. I didn't "get it" I wound up using it in
| 81/82 and got it immediately. Between the gap period I'd moved
| from having the thinnest understanding of what programming was,
| to completing a CS degree and working in systems management and
| networking. Once you have had to use a pre-UNIX JCL such as a
| TOPS-10 system, moving to a unix system was a clear step up. The
| Dec 10 was a fine machine. It was just harder to sequence
| discrete units of code into an outcome. The pipe, and a
| reasonably programmatic shell and related tools were the killer
| app moment.
|
| VMS was good, but it was still sys$system:[thing]/path arcane.
| And had complex database-like file abstractions which I am sure
| were a godsend to people in that space but IPC (using an
| abstraction called "mailboxes") was a nightmare. VMS had file
| versioning, something I think UNIX missed on. ZFS snapshots do
| much the same at a whole of FS level. UNIX still won, because it
| was more logically consistent, and had pipes. BSD4.2 brought
| sockets which I still hate, but they worked inside the
| consistency model.
|
| v7 is where I learned to type. BSD4.1 is where I learned to
| develop. I still have a fond memory for the v7 pdp11.
|
| unix 32V had deep roots in v7, as did the York unix port of v7 to
| the Vax with VM extensions. I think by then, BSD made it clear
| where things were going. System III -> System V were really
| aberrant, streams aside.
|
| If Linux hadn't emerged, I think the BSD fracture would have led
| naturally to something dominant in FreeBSD or NetBSD or OpenBSD.
| But, they lost impetus to mind-share in the world of personal
| computers.
| marcodiego wrote:
| I'm curious: what do you use today?
| ggm wrote:
| OSX which is BSD inside (mostly) ubuntu & debian derived
| stuff on pi4 because "it works" and freebsd on Dell rack
| mounts for systems backends (about ten). Some docker and k8s.
| Some bhyve stuff hosted on a freebsd master. An ix systems
| NAS on their BSD platform.
|
| I lived in netbsd on thinkpad for quite a while. I used
| openbsd for network edge VPN and the like. I talk to a lot of
| BSD people still.
| p_l wrote:
| Funnily enough, BSD Sockets were essentially a crash port of
| code from TOPS-20... (which had much nicer shell than TOPS-10,
| though)
| marcodiego wrote:
| I like the UNIX haters handbook. Mostly for 2 reasons:
| - some of the criticism is reasonable and - today, most of
| those haters probably depend on some form of UNIX one way or
| another.
| leoc wrote:
| The mostly did at the time too, I think. The Handbook's
| sentiment was largely "you can make me use it, but you can't
| make me like it".
| systemBuilder wrote:
| I think many people (myself included) think of V7 plus virtual
| memory plus fast file system plus job control as the ultimate
| pure version of Unix. Add Berkeley sockets from 4.2 BSD and stop
| there. Most of the subsequent work including almost all Linux
| command line implementations have been perverting the Unix
| philosophy: simplicity and minimalism and greatest reusability
| first.
|
| Shared object libraries are a bloatware feature from hell. "Hey
| everybody let's introduce shared libraries into system V so we
| can bloat them and introduce new bugs due to missing or
| incompatible libraries - how does that sound? Because we must
| squeeze the last drop out of every byte of RAM, that's Sooooooo
| important!
| phicoh wrote:
| You probably want a virtual filesystem as well.
|
| You may want kernel modules.
|
| For anything that is not a completely static server you may
| want some kind of devfs.
|
| Then there is the issue of graphics output.
|
| Virtual machines require a bit of kernel support.
|
| What about container support?
|
| Personally I don't like shared libraries, but for people who do
| you need shared memory support.
|
| Multi-threaded programs? Support for multiple CPUs?
| [deleted]
| phicoh wrote:
| I'm a bit confused about the 3rd paragraph. As far as I know, you
| had to have a v6 license for BSD not a v7. I think BSD
| independently implemented v7 functionality.
|
| There also the license change going from v6 to v7. With v7,
| universities where no longer allowed to show v7 source code to
| students. Many universities were teaching operating system
| concepts using v6 source code (and the Lion book).
|
| This inspired Andy Tanenbaum to create MINIX as a v7-like
| operating system written from scratch.
| marcodiego wrote:
| MINIX is the case I use to illustrate the difference between
| source available, open source and free software. The source of
| MINIX was available, but its license was very restrictive.
| Considering it was reasonably functional before linux, the
| world could be a very different place had a better license been
| chosen.
|
| It eventually became open source and the 3.0 was even serious
| but it was too little too late. Besides serving intel's IME,
| there is very little use for it today.
| phicoh wrote:
| The way Andy Tanenbaum tells the story is that he wanted to
| make sure that every student who got a copy of the operating
| systems book, would also get a copy of the source and
| binaries of MINIX. For this reason he insisted that the
| publisher, Prentice Hall, would deliver floppies with book.
|
| Prentice Hall wasn't too keen on doing that but gave in.
| However, as it normally works with publishers, that also
| meant transfering the copyrights to them.
|
| There is another part and that is that Andy Tanenbaum didn't
| consider MINIX a serious operating system. It was designed as
| a teaching aid. Until MINIX-3 he actively resisted adding
| complications, like a virtual memory system. So even with an
| open source license, it probably would have taken a fork and
| rebranding to turn it into a more serious operating system.
|
| Finally, turning a micro-kernel system like MINIX into a
| modern unix system is far from trivial. So it is not clear
| how well an improved version of MINIX would have competed
| with *BSD.
| marcodiego wrote:
| Linux was mostly a toy at first. I see no reason MINIX
| couldn't be as successful.
| p_l wrote:
| Minix 2 design pretty much ensured it couldn't be
| anything more - a lot of early Linux code was about
| replacing Minix code with something that made it less of
| a joke, and the experience was fuel for the tanenbaum-
| linus flamewar (for example, Linus had reentrant,
| "multithreaded" I/O whereas Minix couldn't due to how it
| handled I/O).
|
| It was only Minix 3 when care was taken to include
| possibly more complex but important techniques instead of
| forsaking them for simplicity
| gjvc wrote:
| Very annoying and confusing typo there in first paragraph ---
| CSRG when the author meant CSRC. CSRC was the Bell Labs group
| name, CSRG was the UCB group name.
___________________________________________________________________
(page generated 2021-11-26 23:00 UTC)