Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!sun-barr!rutgers!cbmvax!kevin From: kevin@cbmvax.commodore.com (Kevin Klop) Newsgroups: comp.sys.amiga.tech Subject: Re: Help --> How to prevent the visit from the dreaded guru Keywords: Flip answers are no help Message-ID: <17368@cbmvax.commodore.com> Date: 11 Jan 91 01:21:32 GMT References: <611@caslon.cs.arizona.edu> <1991Jan8.213049.7683@motaus.sps.mot.com> <624@caslon.cs.arizona.edu> <17287@cbmvax.commodore.com> <630@caslon.cs.arizona.edu> Reply-To: kevin@cbmvax.commodore.com (Kevin Klop) Organization: Commodore, West Chester, PA Lines: 61 In article <630@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes: >In article <17287@cbmvax.commodore.com> kevin@cbmvax.commodore.com (Kevin Klop) writes: >>Ummm, it is ALWAYS my GOAL to have a bug free program. As such, as soon as >>someone reports a GURU or bug to me, I fix it and give the fix to everyone >>with a copy of the program. I do NOT blame the OS for my bug, nor believe that >>the OS should be modified in order to "put up" with errors in _my_ code. >> >> -- Kevin -- > >My point is an issue of robustness. Give someone a computer, and the next >thing you know, they want to write a program on it ;). Every time you go >through the program development process, you have to deal with bugs in your >code. Often, these bugs are of a catastrophic nature. I think that expecting >the OS to deal with programs that experience such bugs in a graceful manner >is not unreasonable. I have been taught that program robustness (in dealing >with user input and environment conditions) is nearly as important as program >correctness. Should an OS be held up to any less of a standard? > >I don't blame any OS for bugs introduced by *my* code. But I do believe that >an OS should be as robust as possible in dealing with what a user program >might do. > > >>Kevin Klop {uunet|rutgers|amiga}!cbmvax!kevin >>Commodore-Amiga, Inc. >> >> ``Be excellent to each other.'' >> - Bill and Ted's most excellent adventure >> >>Disclaimer: _I_ don't know what I said, much less my employer. > > >Dave Schaumann | You are in a twisty maze of little >dave@cs.arizona.edu | C statements, all different. The problem with this is the difficulty in a non memory protected model. There is nothing to stop the user program from trashing system structures, passing pointers that ostensibly point to buffers and actually point to program code, etc. to the operating system, nor is there any way to stop a program from trashing some OTHER program's code and data. "So put memory protection in" sounds like a possible answer, but has been hashed over and over again, this is no easy task. The ramifications are pretty far reaching and too detailed for me to get into now. Ditto for resource tracking so that memory, devices, etc. are freed when a program exits. I have more than one program that opens something and then passes the IO request to some OTHER task. The original task then exits. I certainly do NOT want the OS closing that device or deallocating the IO request memory on me. The question you raise, while a valid concern, is a tough one. How much are we willing to trade off? Do we need to put an MMU in the A500s and thereby raise the price of them significantly? If not, then we need two (or more) operating systems. One to deal with MMU systems and one that doesn't. The two OSs would be VERY dissimilar, and would thereby at least double the R&D load here at Commodore. -- Kevin --