Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!mcsun!unido!ira.uka.de!smurf!flatlin!tpki!kris From: kris@tpki.toppoint.de (Kristian Koehntopp) Newsgroups: comp.sys.amiga.advocacy Subject: Re: Amiga OS *IS* state of the art Keywords: Amiga OS Message-ID: <3058@tpki.toppoint.de> Date: 31 Mar 91 09:40:57 GMT References: <1003@cbmger.UUCP> <7827@jhunix.HCF.JHU.EDU> <8806@gollum.twg.com> Organization: Toppoint Mailbox e.V., Kiel, BRD Lines: 169 david@twg.com (David S. Herron) writes: >To have virtual memory: Obviously most Amiga's don't have MMU's, a > required piece of hardware there. Regardless I've never > heard of an OS with virtual memory in which all processes > shared the same space. Currently AmigaDOS processes > share the same space & who knows what will break > when that is changed. Obviously virtual memory has nothing to do at all with seperated address spaces of processes The code needed to install VM on an A3000 or A2500 is below 10 KB, as was demonstrated with the Evolution HDD controller. Also the long exspected System 7 for the Apple Macintosh computer is said to provide VM without seperated address spaces. Since a true PMMU is required for VM, most vendors also chose to integrate address space protection in their systems. If you already have the PMMU on your board, design and performance penalties due to memory protection are not too high considering the gain in system stability. Mac and Amiga are systems which came originally without a PMMU. Thus their OS makes it difficult to take advantages of the ability to separate process address spaces, but VM alone can be implemented below OS level. The OS itself sees only an enlarged RAM and need not to have knowledge of the special nature of this memory. Amiga processes do not change from user to kernel mode, when making calls to libraries, because they call them by simple JSRs. There is simply no concept of operating system private data and code in the current release of Amigas OS. Also there is no defined interface for reading operating system data. This lead to the bad practice of reading operating system structures from user code (eg reading the list of screen structures to find a certain screen or reading dos libraries lock structures etc ). I know that direct reads are faster, but this code will break, if the layout of the read structure changes due to OS upgrades (as in the first releases of KS/WS 2.0). In a properly designed operating system there are calls which return the desired information to you in a well known format. This format can, but need not be identical with the operating systems internal representation of this data. I feel that adding the concept of operating system private data and the distinction of user and kernel mode will break the concept of Amigas OS. Thus we will probably never see memory protection with this system. > Yes I know about MEMF_PUBLIC & etc I remember reading > here, however, that a lot of programmers are lazy about > setting that flag "right" > Obviously a program which needs real time response for > some reason cannot be swapped out. Adding a call to > lock a process in memory would be necessary As you implied in the paragraph above, there is already a mechanism to identify memory with different properties. This mechanism (In OS/9 it is called "colored memory". I find it funny to think about a request for green ram :-) is also supported by the loader. If you had a bit MEMF_VIRTUAL added and your memory had the properties MEMF_VIRTUAL or MEMF_FAST (but not MEMF_PUBLIC), you could easily request true memory (by requesting MEMF_PUBLIC), VM (by requesting MEMF_VIRTUAL) or any type of memory (just request MEMF_FAST or even MEMF_ANY ( == 0)). Since this is also supported by the loader, you can even create a file that is loaded into real mem. Thus such call is not needed. > such) need to be saved away If pointers passed in > system calls are not in public memory (that is, accessible > by every process) then the kernel has to do funny tricks > with the MMU to copy bytes in & out of user memory etc Can you explain? Think of a user process supplying a pointer to a given location. Think of this location as paged out. The OS (or the user process, since it makes no difference) references this location and produces a page fault, that is, an exception. The exception handler pages some other page out (prefereably not the one referenced next!) and the requested page in. The exception handler terminates and operation resumes with the reexecution of the interrupted statement. Of course the exception handler for VM itself better remains in memory, but other exception handlers and interrupt handlers *can* easily be paged out, if memory and not performance is the problem. For interrupts and exceptions which are exspected to be handled in real-time (and better overall system performance) you better allocate real memory. I can see no need for funny tricks here and I believe you were still stuck with the memory protection concept, but of course I may be wrong. >To add memory protection: Again this requires an MMU. Same comments > apply as above. > Both these would be nice though, especially memory protection > for all instead of just for developers. (Aside, there's > a developer tool I've heard about which adds memory > protection as an aid for finding things like wild/NULL > pointers) Well, I guess, you are talking about the enforcer. This program protects the lowest KB of memory against anything but a longword read at loc 4. It also catches writes into ROM-areas and any references to areas without installed memory. All these references are reported and the offending task is identified, but not killed (Killing tasks is difficult with the Amiga Reason see below). Still no memory protection . >Resource tracking: Well, obviously the kernel needs to be keeping > track of what it doles out & that means more code, eh? > I really do NOT understand why this isn't there and don't > see that doing it in a user program versus the kernel > is going to be any faster. Agreed. Ressource tracking or better the lack of it is the second _BIG_ flaw of AmigaOS (With the lack of user vs kernel mode being the first). Of course you can provide code which is called upon termination (also abnormal termination) of a process, but keeping track of any ressource ever used in a programm is a job an application programmer is not supposed to do. Think of an application opening a printer, printing something, the closing the printer. No cleanupnclose()-function will ever bother to check if the printer is still open and close it (the pointer to the printer file could also easily be local and long be gone). But your process can be killed between the open and the close of the printer, leaving the device open and locking all other processes away from the printer. Time for reboot again (For some this has also been the time to junk their Amiga and get a real computer! Pun intended!). With ressource tracking the OS knows about the owner of the open printer and can close it, if necessary, freeing the ressource for other processes. Since AmigaOS already does half-hearted ressource tracking (Well, it knows about free ressources, but not about those alloctated), when will we see the other half? This can be done without breakin the concept of the OS. >Multi-User capabilities: ***WHY*** This is a single user > machine, why do you want others to use it 'sides, > there's some PD-ware about which will do that UUCP > for instance Multi-User capabilities, especially a concept with user identification and file ownership will significantly ease the implementation of any networking environment with AmigaOS. Of course it will be somewhat ridiculous for an A500 owner to log into his 512 KB, single drive system, so one might have this optional. Also there can be no real protection of your data as long as anyone can read the address space of your processes, but file ownership will protect you against accidential deletion or modification of your files. I would like to see the file system extended in a way, that allows the attachment of an arbitrary long list of (attribute, list of values) sets to any file. This is similar to, but not as limited as, the filenotes. On top of this you can implement file ownership (and even be more specific with that than Unix). As you can see, AmigaOS has some big deficiencies. All of them but one can be repaired without forcing it. And this makes AmigaOS a good and state-of-the-art OS: It is able to grow to fit grown needs. ><- "MS-DOS Where we're going we don't need MS-DOS " --Back To The Future Kristian PS: Excuse my bad english. I find it difficult to talk about these things in this strange language, but I hope I was clear enough to bring the essence of it to you. PPS: Please keep any reply to me short, because I have to pay for incoming mail. Kristian Koehntopp, Harmsstrasse 98, 2300 Kiel, +49 431 676689 "Im uebrigen ist 'Z-NETZ-Sysops quaelen' auf Dauer weder lustig noch befriedigend." - sysop@infinet.zer.sub.org