davids@ucscb.UCSC.EDU (Dave Schreiber) (06/10/90)
[And just when you though this topic had been discussed to death...]
A while back (I'm sure you all remember), there was a discussion
regarding putting memory protection into the Amiga OS. As I remember,
the two big problems were:
1. Compatibility
2. Loss of performance, due to the loss of the ability of programs
to access memory allocated by other programs.
Since then I've been reading _Unix Papers for Unix Developers and Power
Users_ by the Waite Group. In it there is a paper regarding porting
Unix to 68030 systems; basically an intro to the '030, its features,
considerations, etc. On pages 444-445, the paper talks about shared
memory:
"Shared-memory segments are a way in which Unix allows two processes
to communicate. ...one process creates an area of memory and allows
it to be shared by other programs. Another process can then request
that this shared memory segment be 'attached' to its logical address
map. Data that is written into the shared segment by one process
can be read from the segment by another process.
Shared-memory segments can be easily implemented using the
MC68030 MMU. [...] Each process can have either read/write or read
only access to the segment."
Although this part of the paper is talking about each process having
its own virtual memory map, it seems reasonable to assume that it
(especially the last sentence) would be the same if the whole system
ran off of one address map.
So, what have I missed here? Is there something else in the Amiga's
OS that makes memory protection difficult to do? If compatibility is
an issue, why not have the OS convert the memory of the message while
its being passed to its destination (i.e. process A sends a message to
process B. Exec makes the memory of the message readable and writable
by both process A and B, then passes it to process B. When B Reply()'s
to the message, remove B's access to it, then pass the reply signal
back to A)?
Note that I'm not taking into consideration the fact that most Amiga's
don't have MMUs; i.e. that memory protection might not be practical
from the financial point of view of Commodore (although I'd be willing
to pay extra for a crash-proof version of Kickstart), but there's
always the future...
--
Dave Schreiber The blue leprechaun
at davids@slugmail.ucsc.edu (prefered but flakey)
or (not both) davids@ucscb.ucsc.edu "Coffee, Darling?"jesup@cbmvax.commodore.com (Randell Jesup) (06/10/90)
In article <4250@darkstar.ucsc.edu> davids@slugmail.UCSC.EDU (Dave Schreiber) writes: >Although this part of the paper is talking about each process having >its own virtual memory map, it seems reasonable to assume that it >(especially the last sentence) would be the same if the whole system >ran off of one address map. Sure, you could have shared pages and private pages, even under a one-memory-space setup. >So, what have I missed here? Is there something else in the Amiga's >OS that makes memory protection difficult to do? If compatibility is >an issue, why not have the OS convert the memory of the message while >its being passed to its destination (i.e. process A sends a message to >process B. Exec makes the memory of the message readable and writable >by both process A and B, then passes it to process B. When B Reply()'s >to the message, remove B's access to it, then pass the reply signal >back to A)? Now you've reached the problem. a) such a "conversion" is expensive at best, impossible (or nearly so) at worst. b) Usually the message includes pointers to other areas of memory, and you must deal with them also - but you have no way of knowing the format of most messages. There are more problems, but most people here know them pretty well by now. :-) -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
valentin@cbmvax.commodore.com (Valentin Pepelea) (06/11/90)
In article <4250@darkstar.ucsc.edu> davids@slugmail.UCSC.EDU (Dave Schreiber) writes: > >A while back (I'm sure you all remember), there was a discussion >regarding putting memory protection into the Amiga OS. As I remember, >the two big problems were: > > 1. Compatibility > 2. Loss of performance, due to the loss of the ability of programs > to access memory allocated by other programs. Actually, performance was never an issue. While fetching a new translation table pointer for every task switch is going to slow down the system, the degradation is insignificant. In fact, it is probably lower than the degradation caused by math coprocessor context switches. > Since then I've been reading _Unix Papers for Unix Developers and Power > Users_ by the Waite Group. In it there is a paper regarding porting > Unix to 68030 systems; basically an intro to the '030, its features, > considerations, etc. On pages 444-445, the paper talks about shared > memory: Of all the operating systems that need studying, I found out that Unix is the cause for most of excess garbage added to streamlined operating systems such as ours. Shared memory though is an exception. :-) > So, what have I missed here? Is there something else in the Amiga's > OS that makes memory protection difficult to do? Well yes, the problem being irreponsability for the last five years. The first problem is the non-useage of the MEMF_PUBLIC flag. Theis flag defines a region of memory that can be accessed by 'other' tasks. Thus if a task want to send a message, it would put it in public memory and signal the other task to pick it up. Public data structures also have to be put in public memory, so that that the operating system may access them. Unfortunately, by definition, this impedes full recovery of a crashing task. Because OS structures have to be put in public memory, any task may access that public memory, and thus cause system lists to get corrupted. Since the cause of a crash is therefore impossible to determine, the crashing task cannot be identified, and the whole machine has to be reset. Another solution would have been to use the mn_length field of a message structure. If that field was used, public memory could be ignored, and the operating system would be informed of the starting and end address of the message. It could then modify the MMU transtalion table of the target task to allow it to access the given message. But then we also have to implement parameter checking. If we send an I/O request to a device driver, and it turns out that the device driver crashes because the parameters were wrong, again we don't know how to recover from the crash, unlkess parameter checking is implemented. Then there's resource tracking. What if a task grabs the DOS device list semaphore, and then crashes. The semaphore should be freed by the operating system, but since we don't have resource tracking yet... To summerize, in order to have memory protection we need to: 1. Redefine and use the MEMF_PUBLIC flag. 2. Use the mn_length field in message structures. 3. Implement parameter checking. 4. Implement resource tracking. Unfortunately, the greatest advantage of the Amiga is that tasks may share data by simply sharing a common memory block. That habit would have to be curtailed for memory protection to work. One thing we could do meanwhile is to come out with tools that make sure applications use the MEMF_PUBLIC flag and mn-length fields correctly. Easy to do. Then when a memory protected operating system came out, most applications would already be compatible. The MEMF_PUBLIC flag should be used right away anyway. We could redefine it to mean "motherboard memory accessible by all processors" in a multi-processing computer. Not using this flag would degrade performance on a multi-processor computer considerably. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
peter@sugar.hackercorp.com (Peter da Silva) (06/11/90)
In article <12521@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: > Of all the operating systems that need studying, I found out that Unix is > the cause for most of excess garbage added to streamlined operating systems > such as ours. Perhaps you are studying the wrong things? Stuff that could be learned from UNIX includes improving the file-locking paradigm (in UNIX all files always appear to be "closed", so (for example) you can read an output file from a background job to check on its progress), and providing transparent access to PIPEs (something that could be entirely hidden in the shell). Kludges like the big-ugly-monolith kernel can be ignored. I highly recommend the original Bell System Technical Journal articles on the UNIX operating system (July/August 1974, I believe). You should be able to find them in your local library. -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ My other car is a hot-air balloon. v "Have you hugged your wolf today?" `-_-'