MESSAGE
| DATE | 2015-09-18 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [LIU Comp Sci] Fwd: Re: fork() on a machine without paging hardware
|
From owner-learn-outgoing-at-mrbrklyn.com Fri Sep 18 11:54:09 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id 04DB4161154; Fri, 18 Sep 2015 11:54:09 -0400 (EDT)
Delivered-To: learn-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id E4210161161; Fri, 18 Sep 2015 11:54:08 -0400 (EDT)
Delivered-To: learn-at-nylxs.com
Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89])
by mrbrklyn.com (Postfix) with ESMTP id 68AA7161154
for ; Fri, 18 Sep 2015 11:54:08 -0400 (EDT)
Received: from [10.0.0.19] (www.mrbrklyn.com [96.57.23.82])
by mailbackend.panix.com (Postfix) with ESMTPSA id 547FB1630B
for ; Fri, 18 Sep 2015 11:54:08 -0400 (EDT)
Message-ID: <55FC33A0.1010700-at-panix.com>
Date: Fri, 18 Sep 2015 11:54:08 -0400
From: Ruben Safir
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: learn-at-nylxs.com
Subject: [LIU Comp Sci] Fwd: Re: fork() on a machine without paging hardware
References:
In-Reply-To:
X-Forwarded-Message-Id:
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Sender: owner-learn-at-mrbrklyn.com
Precedence: bulk
Reply-To: learn-at-mrbrklyn.com
-------- Forwarded Message --------
Subject: Re: fork() on a machine without paging hardware
Date: Tue, 08 Sep 2015 17:49:28 -0500
From: Gordon Burditt
Newsgroups: comp.unix.programmer
References:
> AIUI fork() will duplicate a process' image including its address space.
> After the duplication both parent and child will have the same memory
> image they had before, including having all pointers pointing at the
> same memory locations. So they would both have to have the same data in
> the same places.
This also requires copy-on-write: if one process writes the data
in a page, it gets its own copy. If you can't do that, then
you need to copy immediately on fork().
> That duplication of addresses would normally be made possible by parent
> and child each running in its own address space. That is easy enough to
> achive if the OS has paging hardware available. But what happens if
You need memory management hardware for this, not necessarily paging
hardware, which requires memory management hardware and more.
> there is no paging hardware in use? Surely Unix has run on such
> machines. In that case:
>
> * is fork() prohibited or
fork() had better not be prohibited or the system won't get very
far in booting. It's a fundamental part of running a program.
> * does the OS swap the two tasks out and in or
> * something else?
the OS can swap segments in and out. *OR*, in the extreme I/O-limited
case, it can just be limited by available memory - there is *NO*
swap or page space. That is often the case in modern UNIX systems
when they are being installed, or are booting up. There is no
partition for swap/page space yet, or it hasn't been told to use
it yet. In the case of installation, / is likely located on a
CD-ROM which you just booted, or possibly an in-memory copy of a
filesystem it got from the CD-ROM.
Certain dedicated applications for UNIX, like the "router-on-a-floppy"
(or CD-ROM or DVD-ROM) don't run enough user programs to really
need any swap/page space. If you don't need logs, you can dispense
with having a hard disk.
Consider the Tandy 6000. It ran Microsoft Xenix with a 68000 (not
68020) processor, and had about the crudest memory mapping possible:
it had two base/limit registers which were active only in user mode.
The first base/limit register mapped virtual addresses 0x000000 -
0x7fffff to VAddr + Base1 thru VAddr + Base1 + Limit1. This was
the data segment. If you tried to access past the limit, you'd
get a fault.
The second base/limit register mapped virtual addresses 0x800000 -
0xffffff to VAddr + Base2 thru VAddr + Base2 + Limit2. This was
the code segment, and the user process couldn't write this segment.
If you tried to write the segment or access past the limit, you'd
get a fault.
To run a process, the OS needed to swap both segments of the process
in (if the process *had* a code segment - it was possible to link
everything into the data segment only), load up the base/limit
registers, restore the state of the process and run it. If they
could fit, you could have data and code segments for several processes
in memory at once. You just had to reload the base/limit registers,
along with the processor state, to switch processes. If a program,
like /bin/sh, was linked with shared-text, two processes could share
a code segment if they were both running the same program.
The 68000 did not have useful "page faults" (this is an important
difference between the 68000 and 68020). If it tried to access
memory that wasn't resident, it got a fault, but the instruction
completed. If, for example, it was an add-memory-to-register
instruction, it would take whatever trash was on the bus, and you
just lost the original contents of the register. You couldn't
restart the process; the only choice was to terminate it. So even
running a process with one segment not in memory and faulting it
in when needed wasn't possible.
Shared libraries were not supported. Linking programs shared-text
was a sort of poor-man's shared library. For that to work, you'd
really need another base/limit register, at minimum, and preferably
one base/limit register per shared library a program had. You
*could* sorta support shared libraries by not sharing them, but
there isn't much point in bothering if you can't really share at
least one library in each process.
|
|
