hamish@waikato.ac.nz (03/06/90)
dca@toyland.UUCP writes that he would like code segment protection on amigados, so that errant processes wouldn't stamp on his process. I say Hear Hear! Great idea, just what I said a while ago & got told that it was impossible, because of the way that people abuse the MEMF_PUBLIC flag, and the fact that libraries are shared. So what if the libraries are shared, they don't have to be writable, or even able to be seen by the process currently running. If the library stubs pass a message to the actual routines in the library, & the process sleeps until the routine is finished, (al la Unix Kernel etc). Or is this wrong?? It seems like a solution to me. Then each process just has to have a local jump table (or library header) to use & abuse and the system executes all library code. No more code trashing my errent processes, means a more stable system. Have I made sense to anybody sofar?? Hamish Marson. New Zealand. Disclaimer. All opions are my own & subject to argument!
valentin@cbmvax.commodore.com (Valentin Pepelea) (03/06/90)
In article <208.25f3c82b@waikato.ac.nz> hamish@waikato.ac.nz writes: > >dca@toyland.UUCP writes that he would like code segment protection on >amigados, so that errant processes wouldn't stamp on his process. > >I say Hear Hear! I say there, there! Huh? Where? >Great idea, just what I said a while ago & got told that it was impossible, >because of the way that people abuse the MEMF_PUBLIC flag, and the fact that >libraries are shared. The fact that libraries are shared has nothing to do with it. They don't obstruct memory protection. Neither does the fact that people sometimes forget to specify the MEMF_PUBLIC flag. The problem is that system structures and messages have to be passed in public memory, which by definition can be stomped upon by any task. So if one crashes, the machine can still not recover. >Have I made sense to anybody sofar?? Your argument over shared libraries might be correct, but the question is moot anyway. Now let me rehash something clearly: 1. Memory protection can only be implemented by redefining the MEMF_PUBLIC flag. 2. Then it would be trivial to implement memory protection, but *all* applications would then crash and have to be revised. Even the shared libraries on the workbench disk would have to be revised. If you guys want to give Commodore the mandate to go ahead and drop backwards compatibility completely for the sake of memory protection, then go ahead and say so, but keep in mind that the above two points are the Gospell truth. 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
johnf@stew.ssl.berkeley.edu (John Flanagan) (03/07/90)
In article <10013@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: >Now let me rehash something clearly: > >1. Memory protection can only be implemented by redefining the MEMF_PUBLIC > flag. >2. Then it would be trivial to implement memory protection, but *all* > applications would then crash and have to be revised. Even the shared > libraries on the workbench disk would have to be revised. > >If you guys want to give Commodore the mandate to go ahead and drop backwards >compatibility completely for the sake of memory protection, then go ahead and >say so, but keep in mind that the above two points are the Gospell truth. Here's my vote for the mandate. Document the changes needed in 1.4, and implement them in 1.5 (or 2.0). John Flanagan Space Sciences Laboratory johnf@ssl.berkeley.edu University of California (...!ucbvax!soc1.ssl!johnf) Berkeley, CA 94720 Manners Maketh Man. (415) 643-6308
deven@rpi.edu (Deven T. Corzine) (03/07/90)
On 6 Mar 90 06:30:53 GMT, valentin@cbmvax.commodore.com (Valentin Pepelea) said: Valentin> Your argument over shared libraries might be correct, but Valentin> the question is moot anyway. Now let me rehash something Valentin> clearly: Valentin> 1. Memory protection can only be implemented by redefining Valentin> the MEMF_PUBLIC flag. Well, not exactly true. But EFFECTIVE memory protection would likely require this. Valentin> 2. Then it would be trivial to implement memory protection, Valentin> but *all* applications would then crash and have to be Valentin> revised. Even the shared libraries on the workbench disk Valentin> would have to be revised. All applications? Including any which don't need to allocate any MEMF_PUBLIC memory in the first place? (assuming the system software itself had been updated...) Valentin> If you guys want to give Commodore the mandate to go ahead Valentin> and drop backwards compatibility completely for the sake of Valentin> memory protection, then go ahead and say so, but keep in Valentin> mind that the above two points are the Gospell truth. I don't entirely agree it's gospel truth, but backward compatibility is important enough that this should not be done at this point. Now, the thought of using an MMU for VM (multiple virtual Amigas) is an intriguiging one... then an errant process could crash one virtual Amiga but not the machine as a whole. And you could run software that takes over the machine along with normal stuff. Neat implications. But a bitch to implement. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
news@usc.edu (USENET News) (03/07/90)
Organization: University of Southern California, Los Angeles, CA From: addison@pollux.usc.edu (Richard Addison) Path: pollux.usc.edu!addison In article <1990Mar6.181944.22600@agate.berkeley.edu> johnf@stew.ssl.berkeley.edu (John Flanagan) writes: |In article <10013@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: |>Now let me rehash something clearly: |> |>1. Memory protection can only be implemented by redefining the MEMF_PUBLIC |> flag. |>2. Then it would be trivial to implement memory protection, but *all* |> applications would then crash and have to be revised. Even the shared |> libraries on the workbench disk would have to be revised. |> |>If you guys want to give Commodore the mandate to go ahead and drop backwards |>compatibility completely for the sake of memory protection, then go ahead and |>say so, but keep in mind that the above two points are the Gospell truth. | |Here's my vote for the mandate. |Document the changes needed in 1.4, and implement them in 1.5 (or 2.0). In the documentation for AmigaDOS 1.4 describe the changes needed to correctly support memory protection. Then implement them for an operating system called CAOS. :) --Richard Addison
navas@cory.Berkeley.EDU (David C. Navas) (03/07/90)
In article <23288@usc.edu> news@usc.edu (Richard Addison) writes: >In the documentation for AmigaDOS 1.4 describe the changes needed to >correctly support memory protection. Then implement them for an >operating system called CAOS. :) >--Richard Addison Hear Hear!. Uhm, err, well, I don't suppose anyone has docs on CAOS that we might be able to look at before we throw some weight behind it? :) David Navas navas@cory.berkeley.edu "Think you can, think you can't -- either way it's true." Henry Ford
limonce@pilot.njin.net (Tom Limoncelli) (03/07/90)
[ Random though... but maybe the line-eater will eat it. ] Maybe MEMF_PUBLIC should be tracked as to who uses it and once all those processes are gone, the OS can deallocate them. Just what the Amiga needs, a bunch of graph-theory subroutines! Anyone for graph-theory.library :-) Then, we can have MEMF_NEWPUBLIC which would be followed by calls like "Now_let_process_xxx_have_control_over_that_memory()" or "I_no_longer_ need_access_to_that_memory()" or "I'm_taking_control_away_from_process_ xxx_of_that_memory()". // AAAAGH! I'm partaking in this useless "how to add memory protection" // discussion when I know that *IF* C-A plans on adding MMU support // they'll put better qualified people than myself on the job! -Tom "Guilty of Bandwidth Wasting" Limoncelli -- Tom Limoncelli The computer industry should spend more time in front of tlimonce@drew.uucp their computers. Remember when "Look & Feel" tlimonce@drew.Bitnet was what you tried to do on a date? limonce@pilot.njin.net
djh@dragon.metaphor.com (Dallas J. Hodgson) (03/09/90)
Memory protection this, memory protection that. Simply read_protecting LoadSeg'ged CODE segments would be quite a boost. Likewise, read & write protecting all memory on the freelist would be a big help. Of course, performing the latter would probably run out of memory segment descriptors mighty fast unless AllocMem() was rewritten. Sure, apps could still wildly trash system-common data structures like ExecBase, but it would be a big step forward in preventing tasks from corrupting other tasks & free memory. -djh +----------------------------------------------------------------------------+ | Dallas J. Hodgson | "This here's the wattle, | | Metaphor Computer Systems | It's the emblem of our land. | | Mountain View, Ca. | You can put it in a bottle, | | USENET : djh@metaphor.com | You can hold it in your hand." | +============================================================================+ | "The views I express are my own, and not necessarily those of my employer" | +----------------------------------------------------------------------------+
charles@hpcvca.CV.HP.COM (Charles Brown) (03/12/90)
> If you guys want to give Commodore the mandate to go ahead and drop > backwards compatibility completely for the sake of memory protection, > then go ahead and say so, but keep in mind that the above two points > are the Gospell truth. > Valentin I am in favor of this. There will be a period of pain, but in the end the Amiga will become a much more robust computer. Rather than calling it 1.4 or 1.5, your should probably call it 2.0 since it will not be compatible. -- Charles Brown charles@cv.hp.com or charles%hpcvca@hplabs.hp.com or hplabs!hpcvca!charles or "Hey you!" Not representing my employer.
es1@cunixb.cc.columbia.edu (Ethan Solomita) (03/12/90)
In article <1410044@hpcvca.CV.HP.COM> charles@hpcvca.CV.HP.COM (Charles Brown) writes: >> If you guys want to give Commodore the mandate to go ahead and drop >> backwards compatibility completely for the sake of memory protection, >> then go ahead and say so, but keep in mind that the above two points >> are the Gospell truth. >> Valentin > >I am in favor of this. There will be a period of pain, but in the end >the Amiga will become a much more robust computer. > >Rather than calling it 1.4 or 1.5, your should probably call it 2.0 >since it will not be compatible. >-- > Charles Brown charles@cv.hp.com or charles%hpcvca@hplabs.hp.com > or hplabs!hpcvca!charles or "Hey you!" > Not representing my employer. I think you are all missing an important point. The Amiga barely has enough software as is. MOST amiga owners don't want memory protection. If you go to a completely incompatible 2.0 which is slower than 1.3, you will find software developers abandoning the Amiga right and left, some refusing to support 2.0, and no new sales. Geesh! Even IBM, with 25 million machines AND backward compatibility can't successfully introduce a new operating system, and they are giving people a choice! Before you say that OS/2 takes a super-expensive computer, you should realize that real memory protection will almost require a MMU, which implies a 68020/30 system and thus an expanded computer. This also means that there can't be any such thing as an A500, which currently is the backbone of Commodore (ain't nothing else profitable 8). If you want full protection, the unix amiga should be out real soon now! -- Ethan Ethan Solomita: es1@cunixb.cc.columbia.edu Compu$erve : 70137,3271 Anyone giving away Amigas or Sharp Scanners??? "I'm a polititian. I lie and steal. When I'm not hugging babies I'm stealing their lollypops" -- Red October (probably mungled)
dave@cs.arizona.edu (David P. Schaumann) (03/13/90)
In article <1990Mar12.071759.10106@cunixf.cc.columbia.edu>, es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: [ reams of stuff deleted ] > MOST amiga owners don't want memory protection. [ more stuff deleted ] Not me!!!!!!!!!!!!!! I think the single most obnoxious thing about the amiga is that one buggy program can (and generally will) crash the whole system. IMHO, any multitasking system based on hardware that doesn't provide memory protection is an inherantly unstable machine. Don't get me wrong. I love multitasking... as an aside, I was obliged to use a Mac a while ago, and while noticing how similar the user interface was, I wondered why I didn't see any 'click-to-back' gadgets. Then I realized: ohhhh yeah... no multitasking. So the short answer is that while I like multitasking, even on an unstable platform, it would be worth A LOT to me to see 'core dump' or 'segment fault' or some such when a program goes astray rather than 'Guru meditation... press left mouse key to reboot'. Dave dave@cs.arizona.edu
davidm@uunet.UU.NET (David S. Masterson) (03/14/90)
In article <134@caslon.cs.arizona.edu> dave@cs.arizona.edu (David P. Schaumann) writes: In article <1990Mar12.071759.10106@cunixf.cc.columbia.edu> es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: > MOST amiga owners don't want memory protection. Not me!!!!!!!!!!!!!! Then suggest how it could be done without killing everything already done on the Amiga. Suggest a standard by which it could be achieved. If the standard takes hold, then all you have to do is get hardware/software that conforms to the standard while all those who don't care can continue on as they were. -- =================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mt. View, CA 94043 =================================================================== "If someone thinks they know what I said, then I didn't say it!"
ckp@grebyn.com (Checkpoint Technologies) (03/14/90)
In article <1410044@hpcvca.CV.HP.COM> charles@hpcvca.CV.HP.COM (Charles Brown) writes: >> If you guys want to give Commodore the mandate to go ahead and drop >> backwards compatibility completely for the sake of memory protection, >> then go ahead and say so, but keep in mind that the above two points >> are the Gospell truth. >> Valentin > >I am in favor of this. There will be a period of pain, but in the end >the Amiga will become a much more robust computer. I prefer a dual-standard OS. Let it run unprotected programs (and when they crash, the whole OS and computer crashes) and protected programs concurrently. Allow programs written for 'protected mode' to be run on a machine without an MMU, and consequently without protection. This should provide for an easier upgrade path and will encourage developers to use the new mode even when 90% of Amigas don't have hardware memory protection.
chrisl@caen.engin.umich.edu (Chris Lang) (03/14/90)
In article <19460@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: >In article <1410044@hpcvca.CV.HP.COM> charles@hpcvca.CV.HP.COM (Charles Brown) writes: > I prefer a dual-standard OS. Let it run unprotected programs (and >when they crash, the whole OS and computer crashes) and >protected programs concurrently. Allow programs written for 'protected mode' >to be run on a machine without an MMU, and consequently without protection. What is the point of having memory protection if only SOME programs are protected? I don't see how you can call them "protected" since they are NOT. An unprotected program can crash a protected one? Doesn't sound much like protection to me. -Chris ----- Chris Lang, University of Michigan, College of Engineering +1 313 763 1832 4622 Bursley, Ann Arbor, MI, 48109 chrisl@caen.engin.umich.edu WORK: National Center for Manufacturing Sciences, 900 Victors Way, Suite 226, Ann Arbor, MI, 48108 +1 313 995 0300 "I hate quotations. Tell me what you know." - Ralph Waldo Emerson
ckp@grebyn.com (Checkpoint Technologies) (03/15/90)
In article <492e3b6e.1a5bf@moth.engin.umich.edu> chrisl@caen.engin.umich.edu (Chris Lang) writes: >In article <19460@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: >>In article <1410044@hpcvca.CV.HP.COM> charles@hpcvca.CV.HP.COM (Charles Brown) writes: >> I prefer a dual-standard OS. Let it run unprotected programs (and >>when they crash, the whole OS and computer crashes) and >>protected programs concurrently. Allow programs written for 'protected mode' >>to be run on a machine without an MMU, and consequently without protection. > >What is the point of having memory protection if only SOME programs are >protected? I don't see how you can call them "protected" since they are >NOT. An unprotected program can crash a protected one? Doesn't sound much >like protection to me. Most Amiga's *can't* run protected programs. No MMU. Cost $$$ for hardware (typically a 68030) to fix it, and most people won't. Most developers *won't* write programs specifically for a 68030 Amiga. Bad business move; too few machines. (This'll be hashed for quite a while but I'm certain the final conclusion will be:) You can't protect the existing Amiga software base. There is too much reliance on shared memory without any formalism, and programs use direct access to IO features like the custom chip registers and interrupts. The only way is to write new programs to use new protected-mode features. (My own conslusion) There's no possibility that a 68030-only AmigaDOS protected environment will be successful. Hence my suggestion of a new environment which developers can write programs for, and in an MMU-equipped environment they'll be protected. A new protected environment that replaces the current OS and only runs new protected-mode programs will fail and bring the Amiga down with it. This would eliminate the Amiga's software base. Booting one or the other environment would discourage people from using one or the other, and you can bet the protected environment would be the one to suffer. Therefore I conclude that this new protected environment must co-exist with the current environment.
davidm@uunet.UU.NET (David S. Masterson) (03/15/90)
In article <492e3b6e.1a5bf@moth.engin.umich.edu> chrisl@caen.engin.umich.edu (Chris Lang) writes: In article <19460@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: >In article <1410044@hpcvca.CV.HP.COM> charles@hpcvca.CV.HP.COM (Charles Brown) writes: > I prefer a dual-standard OS. Let it run unprotected programs (and >when they crash, the whole OS and computer crashes) and protected >programs concurrently. Allow programs written for 'protected mode' >to be run on a machine without an MMU, and consequently without protection. What is the point of having memory protection if only SOME programs are protected? I don't see how you can call them "protected" since they are NOT. An unprotected program can crash a protected one? Doesn't sound much like protection to me. The point is support of customers. If you alienate all your customers by making them incompatible with the system in one fell swoop, what have you gained? At least with the dual-standard idea, customers aren't alienated right away -- they migrate to the new standard at their own pace. Naturally, the dual-standard should be something that separates conforming programs from non-conforming programs completely (like the standard of good Amiga code and bad Amiga code). New customers then choose the good code and eliminate the bad over time. Eventually, newer machines with built-in MMUs (not add-in boards) might only support the good standard. -- =================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mt. View, CA 94043 =================================================================== "If someone thinks they know what I said, then I didn't say it!"
hamish@waikato.ac.nz (03/17/90)
I keep reading about people saying that programs should be specially written to cope with memory protection. Memory protection is a function of the OS, not the individual programs. To make it easy to run those programs that would break, then it should be able to be turned on & off, maybe on an individual basis per program. (ie the OS detecting a bounds fault & getting the data or writing the data). This would make it simple to write programs, ie nothing needs changing except how we use the MEMF_PUBLIC flag, which currently seems to be everywhere (correct me if I'm wrong, and the memory allocation routines in the OS itself. One last thing would be a memory handler routine for bad memory accesses by all thos nasty programs out there!. Hamish Marson.
ckp@grebyn.com (Checkpoint Technologies) (03/20/90)
In article <235.260236d8@waikato.ac.nz> hamish@waikato.ac.nz writes: > >I keep reading about people saying that programs should be specially written >to cope with memory protection. Memory protection is a function of the OS, not >the individual programs. To make it easy to run those programs that would >break, then it should be able to be turned on & off, maybe on an individual >basis per program. (ie the OS detecting a bounds fault & getting the data >or writing the data). Well, the problem is that Amiga programs are mostly written with the knowledge that there is no memory protection. So in a sense all Amiga programs are already concerned with memory protection, actually the lack thereof. So when you first make one task's address unreachable by another, that program will crash becayse it had always assumed that it was addressable. In other protected memory systems, the applications are all aware of the memory protection. They must specifically ask for an area of memory to be shared between two or more processes in some way, either by distinguishing between lightweight threads and heavyweight processes, or by creating named shared memory sections, or by opening pipes or message queues of some sort. It's all very formal. In the Amiga, it's all very casual.
markv@kuhub.cc.ukans.edu (03/29/90)
Some thoughts I had on this a long time ago... Why not take a similar route to Protected mode applications that OS/2 and AIX use to run DOS appls. (Hold the groans...) Implement protected mode programs as being protected by virtue of their assumption that all memory is not theirs. All the calls like PutMsg(), GetMsg(), and other things could be written using a new exec library that understands memory protection (and virtual memory). So you would have some new memory flags like: MEMF_VIRTUAL -VM, the default for 'new' applications MEMF_PRIVATE -Memory private to your task. MEMF_SYSTEM -Memory shared with the system, but not other tasks. MEMF_SHARED -(MEMF_PUBLIC is taken and abused) open memory. MEMF_NOSWAP -Things like interuppt handlers, no VM swapping etc. You get the idea. You could also expand the model to distinguish read and write access (for instance GfxBase, etc). A "protected mode" program would get all its segments loaded in private ram (or whatever ram the hunk is flagged for assuming the compliers, linkers, and loaders support the new flags). Functions would be used for all message passing and other interactions with the system and other tasks. On MMU amigas there would be an exec.library that supported and used VM and protection. On non-MMU Amigas the functions would still work, they would just be implemented non-protected. So most protected programs would still run on normal Amigas (assuming they don't need to malloc 6 megs or similar things). On MMU Amigas, the system and protected applications would each run in their own protected space. For non-protected applications, you could use the concept of a 'virtual machine'. Exec would hang out enough of the operating system to pretend to be an old style amiga and un protected applications would run togather in a shared protected space. So a crashing non-protected program would crash other non-protected programs running in this "compatibility box" but the 'real' Exec and protected applications would continue on. You could have several options for the "compatibility box" to control its behavior like wether AllocMems() default to MEMF_VIRTUAL, handing over certain register address spaces to the compatibility box (and protecting the rest) and assume they need to be re-initialized when they're returned, etc. "Most" Amiga programs would continue to run because most Amiga programs DONT scribble all over registers. Their only problem is the assumption that they run in a shared address space and can access certain system structures for information (like IntuitionBase, GfxBase, and ExecBase being the most common). The real hacks would break, but they tend to break every new OS release or hardware change anyways. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: markgood \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~