Path: utzoo!utgpu!watmath!clyde!bellcore!texbell!killer!ames!mailrus!tut.cis.ohio-state.edu!ukma!psuvm.bitnet!cunyvm!ndsuvm1!ndsuvax!ncoverby
From: ncoverby@ndsuvax.UUCP (Glen Overby)
Newsgroups: comp.os.minix
Subject: Re: A few novice questions
Summary: User processes can only SEND-RECEIVE FS, MM
Message-ID: <1803@ndsuvax.UUCP>
Date: 18 Nov 88 16:22:24 GMT
References: <8811081753.AA18094@decwrl.dec.com> <1988Nov9.184419.3709@utzoo.uucp> <13142@ncoast.UUCP>
Reply-To: ncoverby@ndsuvax.UUCP (Glen Overby)
Organization: Silo Tech, Fargo ND USA
Lines: 53


In article <13142@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes:
>As quoted from <1988Nov9.184419.3709@utzoo.uucp> by henry@utzoo.uucp (Henry Spencer):
>| In article <8811081753.AA18094@decwrl.dec.com> powers@cimbad.dec.com (Bill Powers) writes:
>| >  3) If I spawn a couple of processes from a program, is their a mechanism
>| >     for one process to send stuff to another process, like mailboxes in
>| >     VMS.
>|
>| Pipes.
>Try again.  Minix is a message-passing OS; while I haven't tried it -- yet
>-- I haven't noticed anything that would prevent a process from doing
>sendmsg() to another non-kernel process.

Wrong.  User processes can only do a SENDREC (send and receive) to/from FS
and MM.  For the evidence, look in src/kernel/proc.c:

[ ... ]
PUBLIC sys_call(function, caller, src_dest, m_ptr)
[ ... ]
  /* Check for bad system call parameters. */
[ ... Line 106]
  if (function != BOTH && caller >= LOW_USER) {
        rp->p_reg[RET_REG] = E_NO_PERM; /* users only do BOTH */
        return;
  }

[ ... ]
PUBLIC int mini_send(caller, dest, m_ptr)
  /* User processes are only allowed to send to FS and MM.  Check for this. */
[ ... Line 143]
  if (caller >= LOW_USER && (dest != FS_PROC_NR && dest != MM_PROC_NR))
        return(E_BAD_DEST);

>Another -- tabled for the moment -- project of mine has what amounts to a
>"message server" which is capable of queueing messages.  Perhaps such a
>beast should be implemented, similarly to INIT, and all messages be passed
>through it to other parts of the system.

Bing Bang implemented message queueing in his serial TTY driver for V1.2 I
think implementing message queueing in a user process, while feasible, is
the wrong way to go.  It is best implemented in the kernel's own send and
receive functions.  Get Bing's serial driver stuff and look it over; he
changed all the drivers and servers so that they were non-blocking.  I
understand that it actually gave decent multi-processing response time.

A project I've been working on intermittently for about a year now is
revamping the bootstrapper to read Minix from files, and a re-organization
of the priority scheme; I'm switching to privilege bits for processing
priority (device, server, user) and for message sending (open for receive,
privileged for send).  This would allow making certain processes privileged
to send messages to any other process, a potential security breach because
they could then send messages to any device task.

Glen Overby
uunet!ndsuvax!ncoverby  ncoverby@ndsuvax (Bitnet)
ncoverby@plains.nodak.edu