mark@ems.UUCP (01/27/87)
Could someone please enlighten me? I have been looking through the MINIX book (I got mine at UNIFORUM :-) source listings. On page 436, file h/callnr.h is missing the following system call numbers: 11, 26, 31, 32, 34, 35, 38-40, 44, 45, 49-53, and 55-58. Is this due to a desire to keep in line with Version 7 UNIX, or are these 'slots' reserved for future expansion? Is there some historical reason for this, or was it just due to editing, etc?
henry@utzoo.UUCP (Henry Spencer) (02/01/87)
> h/callnr.h is missing the following system call numbers: 11, 26, 31, 32, > 34, 35, 38-40, 44, 45, 49-53, and 55-58. Is this due to a desire to keep > in line with Version 7 UNIX, or are these 'slots' reserved for future > expansion? Is there some historical reason for this, or was it just due to > editing, etc? It's probably V7 compatibility. I don't know why he bothers, since I can't think of any code that knows these numbers which isn't hopelessly hardware- dependent. 11 is exec, obsoleted by exece. 26 is ptrace, which only debuggers use, and there isn't one in MINIX yet. 31 and 32 are stty and gtty, long since superseded by ioctl. 34 is nice, which would actually be useful, but might take a fancier scheduler. 35 is ftime (yields time, fraction-of-second time, timezone, daylight-saving indicator); this omission surprises me. 38-40 are unused in V7. 44 is prof, which only profilers ever use. 45 is unused, as are 49 and 50. 51 is acct, used only by system accounting packages. 52 is phys, which maps physical address space into the process's address space -- unimplementable on an 8088. 53 is lock, which locks the process in core, preventing swapping, which is redundant since MINIX doesn't swap. 55 is unused. 56 is mpxchan, which you *don't* want to know about and neither does Andy. 57 and 58 are unused. -- Legalize Henry Spencer @ U of Toronto Zoology freedom! {allegra,ihnp4,decvax,pyramid}!utzoo!henry
kent@tifsie.UUCP (02/03/87)
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
henry@utzoo.UUCP (Henry Spencer) (02/05/87)
> 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... Actually, lock is a moot point for another reason: no widely-distributed software ever used it. -- Legalize Henry Spencer @ U of Toronto Zoology freedom! {allegra,ihnp4,decvax,pyramid}!utzoo!henry