Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!wuarchive!udel!princeton!phoenix.Princeton.EDU!subbarao From: subbarao@phoenix.Princeton.EDU (Kartik Subbarao) Newsgroups: comp.unix.internals Subject: Re: Implementing a multitasking OS on top of UNIX Message-ID: Date: 9 May 91 13:59:15 GMT References: <1991May9.015124.20638@casbah.acns.nwu.edu> Sender: news@idunno.Princeton.EDU Reply-To: subbarao@phoenix.Princeton.EDU (Kartik Subbarao) Organization: American Chemical Society Lines: 57 In article <1991May9.015124.20638@casbah.acns.nwu.edu> craig@casbah.acns.nwu.edu (Craig Robinson) writes: >For my operating systems class we are required to do the following project: > >"Groups of three students will design and develop a priority based >multitasking kernel that provides for process control, process >synchronization, and process communication. The kernel will be developed in >the C programming language and will run on top of the UNIX OS." > >This is the exact project specification as stated in our syllabus. No >more, no less is required. > >I have several questions I want to ask the gurus. > >1) In what way would we be able to implement a quantum driven system? >How can we simulate clock interrupts? Well, if you're running on TOP of unix, you may not even have to. >2) In UNIX, what happens *at the CPU level* when a process makes a system >call? How does the processor know to switch from user to kernel mode? How >can we simulate this on top of UNIX? When a process makes a system call, many architecturess support some special instruction (it's "trap" on suns). This is a software interrupt, so it indexes into a trap table stored somewhere in memory, and executes whatever code is there. Normally, the OS sets up trap handlers at that place in memory, so it can service the interrupt. >Any other tips anyone can give me would be greatly appreciated, we only have >about 3 more weeks until the due date, and we are all very confused about >exactly how we are going to do this. If you're interested in running on top of UNIX, some versions support LightWeight processes. Lightweight processes appear as just one "process" to UNIX, so they share the same address space. You can "fork" off threads in this process, and they can communicate with each other, etc. SunOS has a whole library to deal with them. I don't know about BSD. Another way you could implement lwp's without an actual library is by using setjmp() and longjump() to implement coroutines. Again, since you're running on top of UNIX, you could steal some of its useful features (like signals) for asynchronous communication. I've just had a blast taking an OS course myself. We built a small OS with sceduling, communication, pipes, the like on top of a bare SPARCstation SLC. It was awesome :-) -Kartik -- internet% ypwhich subbarao@phoenix.Princeton.EDU -| Internet kartik@silvertone.Princeton.EDU (NeXT mail) SUBBARAO@PUCC.BITNET - Bitnet