mark@ccvr1.ncsu.edu (Mark Boyd) (03/07/90)
I'm trying to use messages for process syncronization. I can find no way to use messages between user processes. Has anyone done this? I'm working on 68000 based systems ( ST and PT68k ), but I don't see where the problem would be any different on PCs. Any info would be appreciated, Mark Boyd mark@ccvr1.ncsu.edu
wheeler@IDA.ORG (David Wheeler) (03/10/90)
mark@ccvr1.ncsu.edu (Mark Boyd): > I'm trying to use messages for process syncronization. I can > find no way to use messages between user processes. Has anyone > done this? I'm working on 68000 based systems ( ST and PT68k ), > but I don't see where the problem would be any different on > PCs. > Mark Boyd > mark@ccvr1.ncsu.edu I looked into this problem once.. I think it can be done but haven't tried it myself. I'm not aware of this capability being in the latest version of MINIX, so you'd have to modify the OS. I don't have the latest version of MINIX, so my info is based on the original code.. see the MINIX code as published in "Operating Systems: Design & Implementation", page 473. Lines 1987-1988 and 1950-1953 mean that user processes may only execute a sendreceive, and that user processes may only send to FS or MM. A quick & dirty solution would be to remove these two sections, then recompile MINIX. There may be other sections which make this assumption, but those two sections are certainly a minimum. This would mean that user programs can send to anybody, including internal OS processes. You'll have to be very careful to send to the right places. This modification makes MINIX totally unsecure! A slightly better approach would be to make it so that user programs can only call other user programs OR FS OR MM. I doubt this is bulletproof (security-wise) either, but it's probably a good place to start. For this, eliminate lines 1950-1953 and change lines 1987-1988 to: if (caller >= LOW_USER && (dest != FS_PROC_NR && dest != MM_PROC_NR && dest < LOW_USER)) return(E_BAD_DEST); One probablem is how to get the user process id in the first place: in the short run I'd use a file with an agreed-on name to store the process id. Better yet would be a name server at a set process id (as FS and MM are now). A better approach would be replacing those sections with something more sophisticated, so that certain user processes can talk with certain other processes given certain secure conditions. Other OS's do allow user processes to send & receive messages and have some security checks (perhaps the process sets certain permissions to allow certain other user tasks to send to it, etc, etc). --- David A. Wheeler wheeler@ida.org
siebren@piring.cwi.nl (Siebren van der Zee) (03/16/90)
Have you tried the Amoeba primitives (trans, getreq, putrep)? Implementing message passing on top of RPC should be a two-minute hack. Too bad minix doesn't simply support multithreading: once you do a getreq() you'll hang util someone's kind enough to do a trans() with your port. Altough... using timers & signals you should be able to abort a getreq(), or not? (I'm not a Minix user, as a member of the Amoeba team I'm just curious) Siebren van der Zee, siebren@cwi.nl