Leisner.Henr@xerox.com (Marty) (04/06/88)
I've been rewriting some of the system task to use callgates on a x286 instead of passing messages (since calls like sys_xit, sys_exec, sys_fork only are invoked by mm, there is no need to use the messages as a synchronization mechanism). I've noticed the E_BAD_PROC check is generally of the nature: if (who < 0 || who >= NR_PROCS) result = E_BAD_PROC; Seems like 0 should be LOW_USER_NUMBER unless MM and FS are really allowed to do them. On this note, why not allow MM and FS to fork/exec? If the memory maps are recorded in a place where MM can get at them, wouldn't it be reasonable to run init off the root file system as opposed to including it with the boot disk image? I always found the including of init in the boot image kinda kludgey. marty ARPA: leisner.henr@xerox.com GV: leisner.henr NS: martin leisner:henr801c:xerox UUCP: nsc!nscimg!amps!marty
ncoverby@ndsuvax.UUCP (Glen Overby) (04/08/88)
In article <1903@louie.udel.EDU> Leisner.Henr@xerox.com (Marty) writes: >Seems like 0 should be LOW_USER_NUMBER unless MM and FS are really allowed to >do them. I guess this is on a case specific basis. In general, I think that any server process should be able to do anything that a user process can do. After all, they are a 'real' process, are they not? >On this note, why not allow MM and FS to fork/exec? If the memory maps are >recorded in a place where MM can get at them, wouldn't it be reasonable to run >init off the root file system as opposed to including it with the boot disk >image? I always found the including of init in the boot image kinda kludgey. I agree. A process is a process, there should be no discrimination. I've assumed that MM and FS could fork and exec (guess I better go RTFS again). As for loading Init off of the root filesystem, I think that the ENTIRE system should be loaded off of a filesystem. This doesn't necessarily mean the Root filesystem, either. To put bits behind my ideas, I've been (slowly) working on totally revamping the Minix bootstrap process. I currently have a system in which there are NO patches into the Kernel and FS data space (by a no longer necesary 'build), and have a two-stage bootstrapper which will load Kernel, MM, Fs and Init off of a file system. I'm going to use a configuration file (much like MS-DOS' config.sys) to determine what to load and how to configure the hardware. Some of the other mutations I've been making are to REMOVE some of the ugly defines, like LOW_USER_NUMBER, NR_TASKS, and the requirement that device tasks have a negative process-id number. Those are being replaced with a privilege word (bit oriented) which specifies things like scheduling priority (preemptable/non-preemptable), who can send messages to it, who it can send messages to, and so on. I also plan to be able to load more server processes than just FS and MM. One problem I haven't tackled yet is setting up the ram disk; right now I have NO ram disk (because MM determines memory size by itself). I have been thinking of adding a new 'brk' call which can allocate more than 64K or memory. That would allow the Ram device to simply malloc() the memory that it needs (kinda ugly). Anybody else got a better solution/idea? -- Glen Overby Bitnet: ncoverby@ndsuvax UUCP: {uunet, ihnp4!umn-cs}!ndsuvax!ncoverby