Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!im4u!ut-sally!ut-ngp!infotel!pollux!ti-csl!tifsie!kent
From: kent@tifsie.UUCP
Newsgroups: comp.os.minix
Subject: Re: Re: First MINIX source question
Message-ID: <306@tifsie.UUCP>
Date: Tue, 3-Feb-87 14:24:00 EST
Article-I.D.: tifsie.306
Posted: Tue Feb  3 14:24:00 1987
Date-Received: Wed, 4-Feb-87 07:22:45 EST
References: <7602@utzoo.UUCP>
Organization: TI Process Automation Center, Dallas
Lines: 28

In an article <7602@utzoo.UUCP> Henry Spencer writes:
> [System call #] 53 is lock, which locks the
> process in core, preventing swapping, which is redundant since MINIX doesn't
> swap.                                          ^^^^^^^^^
> Legalize			Henry Spencer @ U of Toronto Zoology
> freedom!			{allegra,ihnp4,decvax,pyramid}!utzoo!henry

Perhaps a better choice of words would be that lock is a moot point, since
MINIX (currently) does not swap.

Perhaps a better design decision (for upgrade capability) would be to
implement the lock system call, and have it merely set a locked-in-core
flag in the kernel process table.  Since MINIX currently doesn't swap,
this would do apparently nothing, but _when_ (not if) some enterprising
hacker(s) adds swapping to MINIX, either to a hard disk or to some
extended/enhanced memory option boards, then the kernel (or more 
correctly, the swapper) could be made to obey the locked-in-core flag.
The cost of the upgrade _capability_ would have only been the additional
flag in the process table, and a short section of code in the kernel
to set the flag when called, and another short section in the kernel
to _reset_ the flag on exec.

Oh well, hindsight is 20-20.
-- 
Russell Kent			Phone: +1 214 995 3501
Texas Instruments - MS 3635	Net mail:
P.O. Box 655012			...!{ihnp4,uiucdcs}!convex!smu!tifsie!kent	
Dallas, TX 75265		...!ut-sally!im4u!ti-csl!tifsie!kent