Path: utzoo!attcan!uunet!lll-winken!lll-lcc!lll-tis!ames!ncar!gatech!udel!mmdf
From: Leisner.Henr@xerox.com (Marty)
Newsgroups: comp.os.minix
Subject: identifying procs -- a proposal
Message-ID: <2509@louie.udel.EDU>
Date: 12 May 88 16:20:54 GMT
Sender: mmdf@udel.EDU
Lines: 33

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