kurt@fluke.UUCP (04/07/87)
Well we BETTER FIGURE OUT how to make messages work over a network. The next "innovation" in personal computers is going to be protected, virtual memory machines. On such a machine a runaway program will have little chance to kill the kernal, and the machine will be expected to run reliably for many consecutive days. One of the things you have to get used to in virtual memory environments is that you can't easily share memory between processes. Right now AmigaDOS cheats -- it passes pointers to memory around in messages. To fix things either all messages will have to exist in a universally accessible memory partition (dangerous), or the memory management will have to allow pairs (or groups?) of processes to share regions of memory (complex) or messages will have to be copied into the receiving process's memory space (expensive?). On networks, you are, of course, pretty much limited to the third choice. I think it is time to decide of AmigaDOS can be modified to deal with virtual memory and/or networking. If not, it is a very bad sign for the amiga.
dillon@CORY.BERKELEY.EDU.UUCP (04/08/87)
>Well we BETTER FIGURE OUT how to make messages work over a network.
You go ahead and figure it out. There is no way one can efficiently
implement the Amiga 'message port' standard over a network. What you do is
implement the Amiga's standard device interface, DOS over the network by
writing a DOS device which allows connections to the DOS device interface on
the remote Amiga's (or the OS of some other arbitrary computer on the network).
Doing so suddenly reduces the types of messages that can be sent
to DOS's well defined set.... You know exactly which messages can be
sent and received and *exactly* what they contain, and thus can implement
'sending' them over the network to a counterpart device on the destination
machine efficiently. You would have something like:
"NET:Amiga15/DF0:charlie" etc...
I.E. a generic program doesn't know or care that this 'file' would
actually be going over the network to DF0: on some other machine.
MMU on an Amiga:
An interesting thought. Currently not feasible except perhaps as
a protection mechanism or to implement virtual memory. The VM would be
limited to a general scheme for the whole machine rather than a 'per process'
scheme used by UNIX (i.e. no duplication of addresses). Implementing an
MMU under the current Amiga enviroment would require resource tracking by
the system.
Even so, you would *not* be able to implement page mapping (the
"all programs start at the same address" model) since arbitrary programs
will reference the same global structures (Windows/Screens/Libraries/Ports) and
pass pointers to each other.
(1) No Address Translation
(2) Entire address space is at least ReadOnly (this solves many
problems right off).
(3) Selected address ranges are R/W depending on the process.
So the question is when to allow a process Write access to some
portion of memory. Let's simplify the task even further:
(4) The OS and ALL LIBRARIES and ALL SYSTEM PROCESSES have full
write access to the entire address space. What does this
solve? Remember that processes usually pass arbitrary pointers
to called library routines.
(5) ALL EXEC DEVICES and DOS DEVICES have full write access to same.
For the same reason... since any number of 'user' processes can
be calling these devices simultaniously, it would be too
inefficient to force these processes to run under the 'protection'
mechanism.
What does this leave us? Well, we have to do full resource tracking,
including tracking of memory allocation (allocating MMU segments and
tracking the segments for each process).
There are still a lot of problems... A process gets a message from another
process containing a pointer to a buffer (which the OS doesn't know about
because it doesn't know what's inside a message). Currently, we can READ
the buffer no-problem, but what about writing to it? What about the message
itself? We have to be able to set the return value...
What about accessing one's Process, Task, and CLI structures? many processes
(e.g. my Shell) have to modify the Process and CLI structures extensively
when running programs under them.
I guess all video memory should always be RW. Even with all the limitations
I've put on to make things reasonable, it is still very easy for a wild user
process to destroy the system.... it could, for instance, munge the message
port's message list. It could just as easily specify some wild pointer to
a library routine (which can write to anywhere)... whoops.
I think it's more trouble than it's worth to implement under AmigaDOS. Of
course, there *are* OS's where you can implement and MMU, VM, etc... UNIX
for instance. One of my projects is such an operating system.
I sometimes crash my Amiga when I'm developing a program (but I've never
lost VD0!), but it has *never* happened to me doing normal non-development
stuff.... and were talking having DME, several invocations of my SHELL,
having two workbench screens (via MWB), all running concurrently with the
Aztec compiler, and my terminal program. Not to mention judious use of
PIPE: and various other DOS devices (VD0:, RAM:).
Believe me, not having an MMU doesn't bother me in the least!
(BTW having 2.5Meg of RAM changes your life!).
-Mattccplumb@watnot.UUCP (04/08/87)
dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >MMU on an Amiga: > > An interesting thought. Currently not feasible except perhaps as >a protection mechanism or to implement virtual memory. The VM would be >limited to a general scheme for the whole machine rather than a 'per process' >scheme used by UNIX (i.e. no duplication of addresses). Implementing an >MMU under the current Amiga enviroment would require resource tracking by >the system. > > Even so, you would *not* be able to implement page mapping (the >"all programs start at the same address" model) since arbitrary programs >will reference the same global structures (Windows/Screens/Libraries/Ports) and >pass pointers to each other. Indeed, using an MMU would require resource tracking. This requires considerable fiddling of AmigaDOS, but AmigaDOS requires considerable fiddling already, so it's no great loss. But address translation could indeed be added to the Amiga architecture. I can't think of any application except debugging that requires access to another process's *text* space. (For non-Unix types, that's where the machine code goes... you know, the stuff that's a pain to make relocatable.) Anything Mem_Alloc'd can easily be made MEMF_PUBLIC (you *do* use that flag, don't you?), and thus globally addressed by all processes. Protection on public memory can be done in a variety of ways (maybe just have it all R/W), but if protection is implemented, there should be calls that can be used to say `let me write to public memory'. (I think all of it together would be easier to use... assigning write permission to sections is a pain.) PopColours is difficult to write otherwise. There is, admittedly, one catch... libraries. I'll have to look over the interface to see if something can be done. They could always be made relocatable, but it would be nice not to have to. How do other machines handle shared libraries? So, we can just divide 4 gig into quarters... private, (public) chip, public fast, and mappable (for debuggers). Even if you don't implement this, an MMU solves one great problem: *fragmentation*. You never have to reboot to fit a big file into your machine. Comments, anyone? With MMU's on the way, a discussion on how to handle them seems appropriate. -- -Colin Plumb (watmath!watnot!ccplumb) Silly quote: There's a dark cloud on every rainbow's horizon.
jesup@steinmetz.UUCP (04/14/87)
In article <12822@watnot.UUCP> ccplumb@watnot.UUCP (Colin Plumb) writes: ... >I can't think of any application except debugging that requires access to >another process's *text* space. (For non-Unix types, that's where the >machine code goes... you know, the stuff that's a pain to make relocatable.) >Anything Mem_Alloc'd can easily be made MEMF_PUBLIC (you *do* use that flag, >don't you?), and thus globally addressed by all processes. ... > -Colin Plumb (watmath!watnot!ccplumb) I think this needs to be re-iterated, and pounded into all Amiga developers heads: If the memory is to be used by ANYONE else, make it MEMF_PUBLIC! This includes messages, packets, task structures, etc. It would be nice if it included even the buffers for Read and Write, but this could be handled transparently, though inefficiently. (allow the fileing system to run with everything mapped, and translate the mapped address to absolute in the Read/Write call before passing the packet to the filing system.) The overhead wouldn't be too bad. I'm afraid that all Chip memory will have to be public, but that's life. At least you won't be able to trash someone elses private code or data. The result of this is a mostly protected system, but since Chip memory (and Public) are writable, it is still possible to blow other tasks (of course, if you move read-only structures like libraries and various other such into public-readonly memory, the consequences should be greatly reduced.) It DOES greatly reduce the chance of blowing other tasks, though. Randell Jesup jesup@steinmetz.uucp jesup@ge-crd.arpa
hand@ece-csc.UUCP (04/19/87)
In article <12822@watnot.UUCP> ccplumb@watnot.UUCP (Colin Plumb) writes: >There is, admittedly, one catch... libraries. I'll have to look over the >interface to see if something can be done. They could always be made >relocatable, but it would be nice not to have to. How do other machines >handle shared libraries? > >So, we can just divide 4 gig into quarters... private, (public) chip, >public fast, and mappable (for debuggers). The VMS operating system for the VAX handles shared virtual memory and also allows processes to share code. I also seem to remember reading that BSD 4.2 was going to allow shared memory but they ran out of time to implement it. These are old issues, and we should definitely look at other machines before reinventing the wheel (as has happened too many times in the micro world). Steve Hand decvax!mcnc!ece-csc!hand Box 7911 ECE Department NC State Univ. (919) 737-2336 ext. 34 Raleigh, NC 27695 (919) 834-4375