Leisner.Henr@xerox.com (Marty) (05/12/88)
I really don't like the way the kernel is organized so tasks have proc numbers <
0, servers have proc #s between 0 and low user and user level procs have
proc_nrs above LOW_USER. I'd much rather have fewer constraints be placed on
numbering/ordering.
It seems there is area number places where proc pointers have to be converted
to proc numbers to determine what type of proc it is (i.e. for sending/receving
messages). I'd also want to be able to install more server tasks after boot
time, so I don't have to munge build anymore than I have to.
A field could be added into the kernel proc table entries to identify the type
of proc. Something like enum { TASK, SERVER, USER }. A setuid root User task
could install itself as a server by executing some magic call. How user level
procs would get the ID of these other server procs for message passing is
another problem.
Something like:
if (caller >= LOW_USER && (dest != FS_PROC_NR && dest != MM_PROC_NR)
would be replaced by
if(caller_ptr->proctype != USER && dest_ptr->proctype != SERVER)
which seems more generic and extensible.
These would also allow some form of process to process communication using the
Minix message passing system. Currently, user procs can't communicate with user
procs.
Comments?
marty
ARPA: leisner.henr@xerox.com
GV: leisner.henr
NS: martin leisner:henr801c:xerox
UUCP: nsc!nscimg!amps!marty
ncoverby@ndsuvax.UUCP (Glen Overby) (05/15/88)
In article <2509@louie.udel.EDU> Leisner.Henr@xerox.com (Marty) writes: >I really don't like the way the kernel is organized so tasks have proc numbers < >0, servers have proc #s between 0 and low user and user level procs have >proc_nrs above LOW_USER. I'd much rather have fewer constraints be placed on >numbering/ordering. >Comments? I have a similar mutation in my system. I added a byte to determine the type of process (USER, SERVER, DEVICE), which is like what you describe. I went one step further; I have a "message privilege" word which specifies: * restrictions for recieving messages * privilege for sending messages If a process has restrictions on recieving messages, only processes which are privileged for sending messages can send to them. If it has no restriciton, anybody can send to it. My hacks of this aren't very well tested yet, and are intermixed with my bootup changes. The main intention of them is to remove "LOW_USER" so that more server processes can be added. I also didn't like the negative process-id number requirement for device tasks. -- Glen Overby Bitnet: ncoverby@ndsuvax UUCP: {uunet, ihnp4!umn-cs}!ndsuvax!ncoverby