Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!yale!umich!umeecs!dip.eecs.umich.edu!gilgalad From: gilgalad@dip.eecs.umich.edu (Ralph Seguin) Newsgroups: comp.sys.amiga.tech Subject: Re: resource tracking Keywords: What is a system call??? Message-ID: <1543@zipeecs.umich.edu> Date: 24 Feb 90 03:35:35 GMT References: <355.25C92297@weyr.FIDONET.ORG> <926@tardis.Tymnet.COM> <352@amgraf.UUCP> <5156@sugar.hackercorp.com> <5159@sugar.hackercorp.com> <9704@cbmvax.commodore.com> <5178@sugar.hackercorp.com> <315@spot.wbst128.xerox.com> Sender: news@zip.eecs.umich.edu Reply-To: gilgalad@eecs.umich.edu (Ralph Seguin) Organization: University of Michigan EECS Dept., Ann Arbor, MI Lines: 65 In article <315@spot.wbst128.xerox.com> mikalsen@bono.UUCP (Thomas Mikalsen) writes: >Last spring I took the Operating System Lab class here at RIT. In the >class we broke up into groups of 3-5 and wrote a multi-tasking O.S. >on Sun-2s. One of the big questions was: do we do it kernal based or >use message passing. Well, being an Amiga owner, and knowing some of >the advantages to message passing, I liked the idea. But, since >a kernal based os is easier to write (we had only 10 weeks) we >went with the KERNAL. > What you are describing is the difference between a heavyweight process system and a lightweight process system. In most heavyweight (ie, most UNIX systems), system, everything is in the kernel. IPC messaging is done by the kernel since it is the only thing allowed to map into the various address spaces without blowing up. The bad things about heavyweight kernels is that they are difficult to change, and sadly, everything, I mean everything, gets stuck down into the kernel (ie, huge kernel). This makes things difficult to deal with. If somebody wanted to make changes, to just the filesystem, then he would have to go and fiddle with the whole kernel , thereby leaving him/herself open to unwanted side effects. In a lightweight process system (MACH, Exec, QuickSilver, etc), it should be relatively easy to make changes to filesystem code, since it is just another process being run outside of the kernel. One other advantage of this is that if the filesystem crashes, it probably won't bring the whole system down, so you can restart the filesystem. Basically a lightweight process system allows multiple execution threads within the same address space, and has the file system and memory management out of the kernel as processes. An attempt is made to minimize the kernel, by just making it handle context switches, messaging and other things that absolutely have to go in there. In a heavyweight process system, you are only allowed one execution point per address space (although you can use coroutines or other such niceties if you want). Everything is placed into the kernel. I love the Amiga's IPC method: nonreplicating messages. Why on earth others haven't seen the wisdom in this is beyond me. Actually, people are starting to catch on. As to what is a kernel call, I'd say that anything to Exec() is a kernel call, since it is really the kernel. Everthing else is just tacked on top. Of course, this doesn't make for a useable system, so in reality, I'd say that a kernel call is anything to any of the libraries. What's a KERNAL anyways? (don't mind me, I'm just being a smart ass). >Tom. >- >Thomas A. Mikalsen "The gold is for us to capture all we want." >Rochester Institute of Technology >- Ralph gilgalad@caen.engin.umich.edu gilgalad@dip.eecs.umich.edu gilgalad@goliath.eecs.umich.edu Ralph_Seguin@ub.cc.umich.edu gilgalad@sparky.eecs.umich.edu USER6TUN@UMICHUB.BITNET Ralph Seguin | In order to get infinitely many monkeys to type 11010 Lighthouse Dr. #234 | something that actually makes sense, you need to Belleville, MI 48111 | have infinitely many monkey editors as well. (313) 697-1048