POSTMASTER@UNO.BITNET (05/26/89)
Deven Corzine <deven@rpi.edu> writes in Message-ID: <DEVEN.89May24025106@daniel.rpi.edu> > Fine. But the RKM's say interrupt code and data MUST be in > MEMF_PUBLIC memory. Why? Interrupt code might be called up by any task in the system. Thus the Exec and the MMU will think that the code executed is part of the calling task. If that code and its data can are not accessible through the MMU by what the Exec thinks is the current task, you get a priviledge violation error. > And yes, virtual memory will have far less damaging effects > than memory protection, with the design of the operating system -- the > message passing mechanism, in particular. I believe I already demonstrated why the contrary is true. Valentin _________________________________________________________________________ "An operating system without Name: Valentin Pepelea virtual memory is an operating Phonet: (613) 231-7476 (New!) system without virtue." Bitnet: 451061@Uottawa.bitnet Usenet: Use cunyvm.cuny.edu gate - Ancient Inca Proverb Planet: 451061@acadvm1.UOttawa.CA
451061@upttawa.BITNET (Valentin Pepeleat) (06/01/89)
Deven Corzine <deven@rpi.edu> writes in Message-ID: <DEVEN.89May30030703@daniel.rpi.edu> > In article <8905291930.AA10122@jade.berkeley.edu> 451061@UOTTAWA.BITNET > (Valentin Pepelea) writes: > > > Faster message passing, faster context switches (no need to copy > > memory and translate addresses (MOVES instruction)), but best of > > all, the ability of programs to access its other address space > > directly. I for one think its really neat to have hacks such as > > Vscreen, Dmouse, Snip-It and others which would be rather impossible > > to implement if the single addressing space was not used. > > Ah, but you see... it basically operates on the assumption that there > is not only a single address space, but no memory protection as > well... Ridiculous! Memory protection merely prevents tasks from overwriting each other. It does not prevent them from reading each other's address space. And by declaring memory to be public, writing in each other's space is allowed too. Read protected memory is useful only in multi-user systems. If you have separate address spaces, then you can not read and write each other's address space. You share data only by sending messages. That is very icky, very Unix-like. Valentin _________________________________________________________________________ "An operating system without Name: Valentin Pepelea virtual memory is an operating Phonet: (613) 231-7476 (New!) system without virtue." Bitnet: 451061@Uottawa.bitnet Usenet: Use cunyvm.cuny.edu gate - Ancient Inca Proverb Planet: 451061@acadvm1.UOttawa.CA
deven@rpi.edu (Deven Corzine) (06/03/89)
In article <8906010339.AA12100@jade.berkeley.edu> 451061@upttawa.BITNET (Valentin Pepeleat) writes: > Deven Corzine <deven@rpi.edu> writes in > Message-ID: <DEVEN.89May30030703@daniel.rpi.edu> > > Ah, but you see... it basically operates on the assumption that > > there is not only a single address space, but no memory protection > > as well... > Ridiculous! Memory protection merely prevents tasks from overwriting > each other. It does not prevent them from reading each other's > address space. And by declaring memory to be public, writing in each > other's space is allowed too. Read protected memory is useful only > in multi-user systems. In some contexts, memory protection DOES mean read-protection as well as write. It's implementation-defined, really. Regardless, the message passing system _depends_ on absence of memory protection. Read AND write. (consider ReplyMsg) And don't count on MEMF_PUBLIC ever being meaningful... > If you have separate address spaces, then you can not read and write > each other's address space. You share data only by sending messages. > That is very icky, very Unix-like. That is very clean. Reading and writing others' address spaces is "icky". Shared memory is often a clumsy method of IPC. Besides, shared memory COULD very well be implemented, ON REQUEST, with read- and write-procted, separately addressed, paged memory. Stop mixing the issues. Deven -- shadow@[128.113.10.2] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>> "Simple things should be simple and complex things should be possible." - A.K.