kent@vf.jsc.nasa.gov (04/04/91)
> > What is the big deal about memory protection and resource tracking? > Sure, it might be a nice toy, but it wouldn't be real useful on a > single-user system. Is this one of those things people want just > because Unix has it? > > Memory protection would prevent a program crash from crashing the whole machine. The memory management unit would limit each program to its own memory space. Thus, the program could not go stomping off into memory with muddy boots. Hence the end of the Guru. Resource tracking would allow the operating system to deallocate all resources a program failed do because it crashed or the programmer did not write code to deallocate all memory, devices and so on. The features are very desireable on any multitasking system. -- Mike Kent - Lockheed Engineering and Sciences Company at NASA JSC 2400 NASA RD One, Houston, TX 77058 (713) 483-3791
jdickson@jato.jpl.nasa.gov (Jeff Dickson) (04/04/91)
In article <1991Apr3.153236.1@vf.jsc.nasa.gov> kent@vf.jsc.nasa.gov writes: >> >> What is the big deal about memory protection and resource tracking? >> Sure, it might be a nice toy, but it wouldn't be real useful on a >> single-user system. Is this one of those things people want just >> because Unix has it? >> >> > >Memory protection would prevent a program crash from crashing the whole >machine. The memory management unit would limit each program to its own memory >space. Thus, the program could not go stomping off into memory with muddy >boots. Hence the end of the Guru. > Memory protection would not be the end of the GURU. I speak from experience. There are other types of errors which can be induced without memory violations. >Resource tracking would allow the operating system to deallocate all resources >a program failed do because it crashed or the programmer did not write code to >deallocate all memory, devices and so on. > Resource tracking is a neat feature, but it would entail greater memory consumption and eat up more cycles. Not closing files or deallocating memory, doesn't cause an immediate system failure. Stomping off into memory with muddy boots does. I think memory protection is more important. -jeff > >-- > >Mike Kent - Lockheed Engineering and Sciences Company at NASA JSC > 2400 NASA RD One, Houston, TX 77058 (713) 483-3791
ben@epmooch.UUCP (Rev. Ben A. Mesander) (04/04/91)
>In article <1991Apr4.034655.3681@uniwa.uwa.oz> andreww@uniwa.uwa.oz (Andrew John Williams) writes: >Something I've always wanted to know - if the problem of no MMU in the >Amiga is because the messages need shared memory, why not make just that >little bit of memory common to any tasks that want it. The rest can be >protected. Add some new calls (or flags) to the OS for requesting >protected memory or message memory. The old software can call the old >routines and get unprotected memory - no change for them. Any new >software can use the new calls. The new software will be more robust, >and thus more popular, so eventually there will be almost no old >software in use. And there's no problem with machines like the 500 with >no MMU - if they ask for protected memory, give them unprotected and >tell them its not. The program won't care - it will just crash worse if >something goes wrong. Which is what we've got now. >So someone tell me where I've gone wrong in my thinking Well, for one thing, the messages can contain pointers to other blocks of memory, rather than the entire message. So that would break your proposed scheme. -- | ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | | ben%servalan.UUCP@uokmax.ecn.uoknor.edu | your mother." - Al Shugart, | | !chinet!uokmax!servalan!epmooch!ben | CEO, Seagate Technologies |
andreww@uniwa.uwa.oz (Andrew John Williams) (04/04/91)
Something I've always wanted to know - if the problem of no MMU in the Amiga is because the messages need shared memory, why not make just that little bit of memory common to any tasks that want it. The rest can be protected. Add some new calls (or flags) to the OS for requesting protected memory or message memory. The old software can call the old routines and get unprotected memory - no change for them. Any new software can use the new calls. The new software will be more robust, and thus more popular, so eventually there will be almost no old software in use. And there's no problem with machines like the 500 with no MMU - if they ask for protected memory, give them unprotected and tell them its not. The program won't care - it will just crash worse if something goes wrong. Which is what we've got now. So someone tell me where I've gone wrong in my thinking John West (stealing Andrew's account) How many fish does it take to screw in a lightbulb?
jep@mtiame.mtia.oz (Jesper Peterson) (04/04/91)
In article <1991Apr4.034655.3681@uniwa.uwa.oz> andreww@uniwa.uwa.oz (Andrew John Williams) writes: |Something I've always wanted to know - if the problem of no MMU in the |Amiga is because the messages need shared memory, why not make just that |little bit of memory common to any tasks that want it. The rest can be |protected. Add some new calls (or flags) to the OS for requesting |protected memory or message memory. The old software can call the old You mean like (c.f.: exec/memory.h): ptr = AllocMem( size, MEMF_PUBLIC ); Of course this flag has been widely misused and any fixed amount of public memory would probably disappear when you start the first application. Any new flag would mean old programs would never get any public memory. I *do* hope this will be resolved one day. Jesper. -- ------------------------------------------------------------------------ USEnet: jep@mtiame.mtia.oz.au UUCP: ...!uunet!munnari!mtiame.oz!jep 90% of everything is IBM compatible - Paraphrased From Theodore Sturgeon
markv@kuhub.cc.ukans.edu (04/08/91)
In article <1991Apr4.074540.27750@mtiame.mtia.oz>, jep@mtiame.mtia.oz (Jesper Peterson) writes: > In article <1991Apr4.034655.3681@uniwa.uwa.oz> andreww@uniwa.uwa.oz (Andrew John Williams) writes: > |Something I've always wanted to know - if the problem of no MMU in the > |Amiga is because the messages need shared memory, why not make just that > |little bit of memory common to any tasks that want it. The rest can be > |protected. Add some new calls (or flags) to the OS for requesting > |protected memory or message memory. The old software can call the old > > You mean like (c.f.: exec/memory.h): > > ptr = AllocMem( size, MEMF_PUBLIC ); > Of course this flag has been widely misused and any fixed amount of Ehh, toss that. With a new OS, rename AllocMem to OldAllocMem(), and then provide a NewAllocMem(). OldAllocMem would always return public memory, new AllocMem would respect the flags. You also would need to add some flags like MEMF_NOSWAP or such for things like DMA buffers and Interrupt code. Another (worse) problem, is that many programs still use static data for public memory. Then we just need a new keyword like "public" that can apply to data *and* functions (for callback support). AllocMem() would have to get a lot more intellegent, because it would have to manage a heap for each process (since most allocations will never be a multiple of the page size). A protected Amiga OS could "partially" do away with the shared address space. New Amiga programs that support the new calls and flags would get a private address space for protected non-public RAM, and maybe the stack (a Unix style stack would be nice), and public/shared RAM would get allocated out of a shared public pool. Also, most "public" activity is program to system, or at least parent to child, so the OS could be modified so that this kind of I/O doesn't need to have explicitly public by Exec etc, using the tasks memory map for access. This would increase the robustness of the system even more. > public memory would probably disappear when you start the first > application. Any new flag would mean old programs would never get > any public memory. I *do* hope this will be resolved one day. I really think it could be done. Each "new" program gets run in its own protected address space. There is a non-protected address space for true public and old style programs. That way new programs would only kill themselves, and old programs could only kill other old programs. Go one step further and provide some IPC routines that dont require totally public RAM, that way applications could trade speed for robustness. Note that even old programs (in 90% of the cases) wouldn't be hard to convert. It would only be a matter of going back and fixing the problem practices (most of which shouldn't be done anyways, like misuse of the MEMF_PUBLIC flag), and recompiling. > > Jesper. > -- > ------------------------------------------------------------------------ > USEnet: jep@mtiame.mtia.oz.au UUCP: ...!uunet!munnari!mtiame.oz!jep > 90% of everything is IBM compatible - Paraphrased From Theodore Sturgeon -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: mgooderum \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~