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