ckp@grebyn.com (Checkpoint Technologies) (08/09/89)
In article <7570@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: > > Many requests for what people call "resource tracking" are actually >requests for memory protection. I consider any program on ANY os that doesn't >free what it allocates (memory, file locks, whatever) to be at best poorly >written. > Well let me register myself as one who really wants resource tracking, complete and unabridged. By this I mean more than memory protection, I mean the ability to have a process fault and the system clean up all the resources it held at the time - file locks, semaphores, allocated memory, windows, screens, devices... everything. And then the system continues to run. This is what I mean by resource tracking. To me, memory protection is just a way to decide *when* to fault a program (when it treads on unowned memory), just as would an illegal instruction trap or address error. -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
jms@tardis.Tymnet.COM (Joe Smith) (10/27/89)
In article <8910232238.AA18077@en.ecn.purdue.edu> bevis@EE.ECN.PURDUE.EDU (Jeff Bevis) writes: >If one were to keep track of process resources, what would one be keeping >track of, aside from memory, message ports, file locks, and, perhaps, >semaphores? I've not really given this much thought, but I would like to >know what the scope of full resource tracking is. Make sure the design is flexible enough to allow one process to create another process and give resources to the second process. We need a way to tell the resource tracker things like: "This memory now belongs to that process, as do these file locks, this viewport, etc." Programs that come in two parts, like c:dmouse and l:dmouse-handler can cause all sorts of headaches to simple-minded resource trackers. Summary: It can be done, but not without changes to both the OS and to the programs. -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@gemini.tymnet.com McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
filbo@gorn.santa-cruz.ca.us (Bela Lubkin) (10/27/89)
In article <8910232238.AA18077@en.ecn.purdue.edu> Jeff Bevis writes: >If one were to keep track of process resources, what would one be keeping >track of, aside from memory, message ports, file locks, and, perhaps, >semaphores? I've not really given this much thought, but I would like to >know what the scope of full resource tracking is. Most importantly, allow new types of resources to be added dynamically. A program should be able to declare a new type of resource, "volunteering" to handle tracking of that resource. The implementation should provide routines to manage generic resources, so that the program declaring a new type of resource needs only minimal code to handle what is unusual about its resource type. Given this, the basic resource tracking manager could be limited to what you list above: memory, message ports, file locks, semaphores, and one addition: resource definitions. Bela Lubkin * * // filbo@gorn.santa-cruz.ca.us CompuServe: 73047,1112 @ * * // ....ucbvax!ucscc!gorn!filbo ^^^-VERY slow [months] R Pentomino * \X/ Filbo @ Pyrzqxgl +408-476-4633 & XBBS +408-476-4945
Jeff.Petkau@weyr.FIDONET.ORG (Jeff Petkau) (02/02/90)
Warning: If you do not enjoy watching the physical abuse of dead horses, stop reading this message. From article <130652@sun.Eng.Sun.COM>, by cmcmanis@stpeter.Sun.COM (Chuck McManis): > Think again. It isn't trivial, (let's here how you would do it in 1000 > words or less) and 90% of the time the cost in terms of extra code isn't > worth the hassle. You have to remember the entire Amiga kernel, some > supporting libraries and a couple of device drivers fits into 256K of > ROM. Compare and contrast how this would effect performance of simple > routines versus making sure routines that care are accurate. It _is_ trivial. For memory, simply keep a pointer in the task structure to the same sort of list that C compilers use for malloc(), or use intuition's Remember lists (automatically, that is.) For most other things (screens, windows, filehandles, locks, libraries, fonts...) keep a list of something like struct FunkyRemember { void (*CloseFunc)(); /* the function to close this object */ long Arg; /* the argument to pass closefunc */ struct FunkyRemember *Next; }; Now, say you call OpenScreen(). OpenScreen will create a new FunkyRemember with CloseFunc=CloseScreen, Arg=the screen pointer and link it into the list kept in your task structure. A special function could be provided to delink a resource from the list without closing it, in case you wanted to close it manually or keep it around after your program exited. The only basic requirement here is that all the CloseXXX() functions take a single parameter, and all in the same register. The only existing functions that might have trouble with are OpenDevice() and CloseDevice(), since they use the user's ioreq structure for closing. A patch would still be trivial, though; just provide a DirectCloseDevice() which takes the io_Device field instead of the ioreq containing it, and use that for the remember list. -- Jeff Petkau - via FidoNet node 1:140/22 UUCP: alberta!dvinci!weyr!Jeff.Petkau Internet: Jeff.Petkau@weyr.FIDONET.ORG Standard Disclaimers Apply...
cmcmanis@stpeter.Sun.COM (Chuck McManis) (02/04/90)
Warning: If you do not enjoy watching the physical abuse of dead horses, stop reading this message. In article <355.25C92297@weyr.FIDONET.ORG> (Jeff Petkau) writes: >It [resource tracking] _is_ trivial. For memory, simply keep a pointer ... Jeff goes on to explain something that looks a bit like the ARP resource tracking code. The ARP code does this fairly well and actually takes it a step further in that you can have "deallocator" functions that will deallocate the specific resource etc etc. BUT, and this is the killer, WHY do people want resource tracking? There are two reasons, the second is so that a program can just call exit() and have anything that it had allocated freed. That is the easy one. The first and foremost reason that people want resource tracking for is so that they can somehow kill an errant process and have it automatically free up it's resources. By definition, IT IS NOT POSSIBLE TO GUARANTEE THAT THIS WILL WORK. Why? Because you cannot know in a non-MMU based system just what the heck the "errant" process stomped on. You can "play the odds" which is what GOMF does and GUESS that the process didn't do any unknown damage to the system lists, but you cannot GUARANTEE it. The difference is the same between a hack and a product. It is _non trivial_ to make this possible in the Amiga system. Something I personally would like to see would be a "runprotected" command that would start a program and setfunction the appropriate vectors so that the program would run with the MMU protecting all addresses outside of it's range. (determined at LoadSeg time and after each call to AllocMem) It need only protect them from Write Access and could stop the program when it did something stupid. Too bad Valentin already has his degree this might be a good thesis project :-) This would be a great debugging tool and allow a developer to release it with confidence on the unsuspecting user community *knowing* that it doesn't do weirdo writes outside of its address space. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "If it didn't have bones in it, it wouldn't be crunchy now would it?!"
ben@contact.uucp (Ben Eng) (02/05/90)
In article <355.25C92297@weyr.FIDONET.ORG> Jeff.Petkau@weyr.FIDONET.ORG (Jeff Petkau) writes: >or use intuition's Remember lists (automatically, that is.) For most >other things (screens, windows, filehandles, locks, libraries, >fonts...) keep a list of something like > > struct FunkyRemember { > void (*CloseFunc)(); /* the function to close this object */ > long Arg; /* the argument to pass closefunc */ > struct FunkyRemember *Next; > }; > >Now, say you call OpenScreen(). OpenScreen will create a new >FunkyRemember with CloseFunc=CloseScreen, Arg=the screen pointer and >link it into the list kept in your task structure. It is not quite as trivial as it sounds. Some resources such as Windows are dependent upon other resources (ie. a Screen) being already allocated. If you don't deallocate the resources in the correct order, things will blow up miserably. Many Intuition type resources will require special coding to handle this anyway. General-purpose resource tracking is great if you want to be able to kill a program, or if your program only deallocates its resources when it exits. Half the time, a programmer will probably find himself dynamically allocating a resource and returning it to the system as soon as the program is finished with it. The latter case would require the extra code anyway. Ben -- Ben Eng | ben@contact.uucp _or_ ben@ziebmef.mef.org 150 Beverley St. Apt #1L | Bix: jetpen ^^^-down for repair? Toronto, Ontario M5T 1Y6 | UofT Engineering Science: engb@ecf.toronto.edu _-_-_-_-_-_-_-_-_-_-_-_-_| Phone: (416)-979-7885, (416)-979-8761
jms@tardis.Tymnet.COM (Joe Smith) (02/07/90)
In article <355.25C92297@weyr.FIDONET.ORG> Jeff.Petkau@weyr.FIDONET.ORG (Jeff Petkau) writes: >Warning: If you do not enjoy watching the physical abuse of dead horses, stop reading this message. >It _is_ trivial. For memory, simply keep a pointer in the task >structure to the same sort of list that C compilers use for malloc(), It is NOT trivial. If we were to take your suggestion and automatically free ALL memory a task allocates but does not free, then a lot of current programs would would get random guru's after they exit. There are a lot of programs that allocate memory and deliberately do not free the memory because they give that chunk of memory to another task. (One example would be a do-it-yourself CD program - the memory used to hold the lock belongs to the system, not the task, after calling the CurrentDir function.) Unfortunately, the current OS is missing calls to the Exec to say "please pass the ownership if this resource to that task". Unix does not have this problem since there are no other tasks sharing your virtual address space. All memory gotten via malloc() can be freed with no problem. But AmigaDos has several tasks sharing a single address space. The Amiga has problems not shared with other Operating Systems. Resource tracking can be done. But making it transparent to the programmer and work with existing software is an almost impossible task. I'd like to see it done right. But I'm afraid that it may take an incompatible release of the OS - one where the current programs do not run. -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C41 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga speaks for me."
huver@amgraf.UUCP (Huver) (02/09/90)
In article <926@tardis.Tymnet.COM>, jms@tardis.Tymnet.COM (Joe Smith) writes: > ... > Unix does not have this problem since there are no other tasks sharing your > virtual address space. All memory gotten via malloc() can be freed with no > problem. Not so fast. UNIX IPC provides posting/sharing preset and/or allocated memory blocks among processes (that don't have to be forked in the same family). Such m/calloc'd memory certainly cannot be freed "with no problem". In fact, processes can simply go away and not tell the kernel anything about releasing the shared memory ID numbers. UNIX at this point is not at liberty to reclaim them, because there is no way for it to tell if some time later a new process isn't going to ask for such a shared memory. Is it logical to ask an opreating system to guard against incompetent/ ignorant/lazy programmers who do not act responsible for their own actions? If a person is not supposed to throw dirty socks around the house, whether he/she lives alone or not, why is it "a good idea" that some O/S should provide resource tracking? The computer is supposed to follow you closely and silently pick up the dirty socks you throw around, is that it?
ckp@grebyn.com (Checkpoint Technologies) (02/10/90)
In article <352@amgraf.UUCP> huver@amgraf.UUCP (Huver) writes: >Is it logical to ask an opreating system to guard against incompetent/ >ignorant/lazy programmers who do not act responsible for their own actions? For a time-shared multi-user operating system - Yes. In fact, not only should a multi-user operating system protect against incompetent/ignorant programmers, it needs to protect against malicious/ evil/destructive ones too, those which are bent on the system's downfall. Unix definitely falls into this category. AmigaDOS does not; it's a single user PC and single user OS, and that's why I think lack of resource tracking and memory protection is not gross negligence, just a reasonable design compromise. Memory protection is expensive - the cost of an MMU. Resource tracking probably should have been there, and in fact CAOS (the original, undelivered Amiga OS) had it, but Amiga had to abandon that and use Tripos instead.
Jeff.Petkau@weyr.FIDONET.ORG (Jeff Petkau) (02/12/90)
>> [A long bit quoted from me] > It is not quite as trivial as it sounds. Some resources such as > Windows are dependent upon other resources (ie. a Screen) being > already allocated. If you don't deallocate the resources in the > correct order, things will blow up miserably. But the correct order is almost invariably the opposite of that in which they were allocated. Even when it is not, the order will often be unimportant. What I described (or the equivalent of ARP's resource tracking, done automatically) would be enough to allow you to kill off most programs with very little mess. Someone else pointed out that some programs mess around with various system structures, and that killing them would leave the computer very unhappy. So what? Set some flag somewhere to warn that killing this particular process right now is a bad idea. It's impossible to handle every imaginable scenario perfectly, but that's no excuse to refuse to touch any of them. -- Jeff Petkau - via FidoNet node 1:140/22 UUCP: alberta!dvinci!weyr!Jeff.Petkau Internet: Jeff.Petkau@weyr.FIDONET.ORG Standard Disclaimers Apply...
850031m@aucs.uucp (Ross MacGregor) (02/13/90)
In article <352@amgraf.UUCP> huver@amgraf.UUCP (Huver) writes: > ... > >Is it logical to ask an opreating system to guard against incompetent/ >ignorant/lazy programmers who do not act responsible for their own actions? > >If a person is not supposed to throw dirty socks around the house, whether >he/she lives alone or not, why is it "a good idea" that some O/S should >provide resource tracking? The computer is supposed to follow you closely >and silently pick up the dirty socks you throw around, is that it? Ahh, but the whole house doesnt come down just because you left a few dirty socks lying around. :-) -ross -- --------- Ross MacGregor | " Elvis Lives - I E-mail: 850031m@AcadiaU.CA | heard him on the UUCP: {uunet|watmath|utai}!cs.dal.ca!aucs!850031m | radio yesterday"
jwz@teak.berkeley.edu (Jamie Zawinski) (02/14/90)
In article <352@amgraf.UUCP> huver@amgraf.UUCP (Huver) writes: > If a person is not supposed to throw dirty socks around the house, whether > he/she lives alone or not, why is it "a good idea" that some O/S should > provide resource tracking? The computer is supposed to follow you closely > and silently pick up the dirty socks you throw around, is that it? Some of us call that "Garbage Collection."
karl@sugar.hackercorp.com (Karl Lehenbauer) (02/16/90)
In article <352@amgraf.UUCP> huver@amgraf.UUCP (Huver) writes: >Not so fast. UNIX IPC provides posting/sharing preset and/or allocated >memory blocks among processes (that don't have to be forked in the same >family). Such m/calloc'd memory certainly cannot be freed "with no problem". Regular memory allocation calls probably happen ten thousand times more often than IPC stuff. IPC is the exception, and it is there specifically to allow sharing between process and as such, sure, you have to have some plan for cleaning up. But the normal Unix program can dump core with impunity and still get its normal memory freed without doing anything, which is nice. Yeah, not having resource tracking on the Amiga is a bummer, but I've gotten used to it, developed some tools, etc, so it's not so bad. -- -- uunet!sugar!karl "As long as there is a legion of superheros, all else -- can surely be made right." -- Sensor Girl -- Usenet access: (713) 438-5018
peter@sugar.hackercorp.com (Peter da Silva) (02/16/90)
In article <5156@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes: > Regular memory allocation calls probably happen ten thousand times more often > than IPC stuff. IPC is the exception... On UNIX IPC is the exception. On the Amiga, IPC is the norm. Every system call is actually a message passed to another program. All these messages have to be tracked, and while it would have been possible to do this (say, by passing a size with the message so the memory ownership could be handled by the O/S), it wouldn't be easy. Think about what happens when a driver replies to a task that's been killed. Of course, the alternative is for the *task* to handle this, and that's really no easier... but it's not such an unreasonable thing for Amiga to have left out considering the circumstances. -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ I haven't lost my mind, it's backed up on tape somewhere! v "Have you hugged your wolf today?" `-_-'
valentin@cbmvax.commodore.com (Valentin Pepelea) (02/17/90)
In article <5159@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >On UNIX IPC is the exception. On the Amiga, IPC is the norm. Every system >call is actually a message passed to another program. Whoa! Come on, you know better than that! I can name a huge number of system calls which do not end up send a message somewhere else. In fact, I have a lot of difficulty identifying the calls which actually do send a message. They're pretty rare. 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) (02/18/90)
In article <9704@cbmvax.commodore.com> valentin@cbmvax.cbm.commodore.com (Valentin Pepelea) writes: > In article <5159@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >On UNIX IPC is the exception. On the Amiga, IPC is the norm. Every system > >call is actually a message passed to another program. > Whoa! Come on, you know better than that! I can name a huge number of system > calls which do not end up send a message somewhere else. In fact, I have > a lot of difficulty identifying the calls which actually do send a message. > They're pretty rare. If I interpret you correctly, you've misinterpreted me. In UNIX, message passing is the exception. In the Amiga, "system calls" are all messages. So you're just saying the same thing I said: in UNIX, IPC is the exception. -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ I haven't lost my mind, it's backed up on tape somewhere! v "Have you hugged your wolf today?" `-_-'
papa@pollux.usc.edu (Marco Papa) (02/19/90)
In article <5178@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <9704@cbmvax.commodore.com> valentin@cbmvax.cbm.commodore.com (Valentin Pepelea) writes: >> In article <5159@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: || |On UNIX IPC is the exception. On the Amiga, IPC is the norm. Every system || |call is actually a message passed to another program. | || Whoa! Come on, you know better than that! I can name a huge number of system || calls which do not end up send a message somewhere else. In fact, I have || a lot of difficulty identifying the calls which actually do send a message. || They're pretty rare. | |If I interpret you correctly, you've misinterpreted me. In UNIX, message |passing is the exception. In the Amiga, "system calls" are all messages. ^^^^^^^^^^^^ ^^^ Well, on the Amiga ALL system calls are done through libraries. Name me one system call in graphics.library that is a "message". Or even take exec.library or dos.library. Get your facts, Peter. Generalizing (i.e. using attibutes like "all") without checking it out often results in making dumb statements like the one above. -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
valentin@cbmvax.commodore.com (Valentin Pepelea) (02/19/90)
In article <131188@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: > >Something I personally would like to see would be a "runprotected" command >that would start a program and setfunction the appropriate vectors so that >the program would run with the MMU protecting all addresses outside of it's >range. > >It need only protect them from Write Access and could stop the >program when it did something stupid. Too bad Valentin already has >his degree this might be a good thesis project :-) Not that I did not think about it. The problem is that I can not achieve full recoverability if a task goes astray. The problem lies with the definition and useage of MEMF_PUBLIC. Memory defined as such is free to be written to by any task or interrupt in the system. That's where all the system structures are. So if one task crashes, even if the MMU protects other private memory, it could be that a portion of MEMF_PUBLIC memory got corrupted by some other task, and that eventually resulted in the crash under the context of the current task. Full recoverability in a memory protected system can therefore be achieved only by changing the definition of the MEMF_PUBLIC flag, and by adding parameter checking to all system functions that cause another task or interrupt to execute some code. For example the DoIO() function causes a device to process a request. If the request provided is scrambled, a crash will occur under the device's context. Both these changes would cause some programs to fail, if implemented. So for backwards compatibility reasons, it is unlikely that memory protection will ever be implemented on AmigaDOS. I for one would gladely implement them as they require no great engineering effort, but the god in the corner office is unlikely to approve, for backward compatibility reasons. >This would be a great debugging tool and allow a developer to >release it with confidence on the unsuspecting user community >*knowing* that it doesn't do weirdo writes outside of its address >space. As a debugging tool, "runprotected" would still make sense, since many illegal memory accesses would be detected this way. In fact, we already have two such utilities in-house. Both trap accesses to page zero (0x000000-0x000100) and above 16 Meg, send out a status report on the serial port at 9600 baud, and then complete the memory accesses manually. One was written by Bryce and the other by me. We like so much to double engineering efforts, you see. Of course, mine is muchg better written. :-) 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
valentin@cbmvax.commodore.com (Valentin Pepelea) (02/19/90)
In article <5178@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <9704@cbmvax.commodore.com> valentin@cbmvax.cbm.commodore.com (Valentin Pepelea) writes: > >> Whoa! Come on, you know better than that! I can name a huge number of system >> calls which do not end up send a message somewhere else. In fact, I have >> a lot of difficulty identifying the calls which actually do send a message. >> They're pretty rare. > >If I interpret you correctly, you've misinterpreted me. In UNIX, message >passing is the exception. In the Amiga, "system calls" are all messages. >So you're just saying the same thing I said: in UNIX, IPC is the exception. No, I was referring to AmigaDOS. There are many system calls in AmigaDOS which do not result in sending messages. It is easy to identify those that do in the Exec, but I have trouble identifying the Intuition or graphics calls that do. But then, I'm no intuition Guru. 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
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (02/19/90)
In <5178@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <9704@cbmvax.commodore.com> valentin@cbmvax.cbm.commodore.com (Valentin Pepelea) writes: >> In article <5159@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >> >On UNIX IPC is the exception. On the Amiga, IPC is the norm. Every system >> >call is actually a message passed to another program. > >> Whoa! Come on, you know better than that! I can name a huge number of system >> calls which do not end up send a message somewhere else. In fact, I have >> a lot of difficulty identifying the calls which actually do send a message. >> They're pretty rare. > >If I interpret you correctly, you've misinterpreted me. In UNIX, message >passing is the exception. In the Amiga, "system calls" are all messages. > >So you're just saying the same thing I said: in UNIX, IPC is the exception. Hmm. Unless you have recently redefined the meaning of 'system call' and 'message', they are two quite different animals. While it is true that many system calls eventually wrap your parameters in a message and dispatch it, there are also many system calls that never dispatch a message. Take the example of the Exec call DoIO. It is indeed a system call, in that no mesage is built by the programmer. Load up the regs (or stack the parms and let the glue load up the regs), and JSR. No message. DoIO does build a message, of course, and ships it off to the driver, but that doesn't make DoIO() any less of a system call. Heck, it's right there in exec.library, implemented as a jump into a ROM routine. Please note that I am not disputing your claim that in Unix, IPC is the exception. Just pointing out that on the Amiga, a system call may or may not generate a message. -larry -- Gallium Arsenide is the technology of the future; always has been, always will be. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
richard@stb.uucp (Richard Conner) (02/19/90)
In article <9716@cbmvax.commodore.com> valentin@cbmvax.cbm.commodore.com (Valentin Pepelea) writes: >In article <131188@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >> >>Something I personally would like to see would be a "runprotected" command >>that would start a program and setfunction the appropriate vectors so that >>the program would run with the MMU protecting all addresses outside of it's >>range. > >Not that I did not think about it. The problem is that I can not achieve full >recoverability if a task goes astray. The problem lies with the definition >and useage of MEMF_PUBLIC. Memory defined as such is free to be written to >by any task or interrupt in the system. That's where all the system structures >are. > [...] >Full recoverability in a memory protected system can therefore be achieved only >by changing the definition of the MEMF_PUBLIC flag, and by adding parameter >checking to all system functions that cause another task or interrupt to >execute some code. For example the DoIO() function causes a device to process >a request. If the request provided is scrambled, a crash will occur under the >device's context. I can live with that... I don't think you really mean you need to change the definition of MEMF_PUBLIC -- just the current (ahem) "usage" by perhaps less-than-competents who can't read? >Both these changes would cause some programs to fail, if implemented. So for >backwards compatibility reasons, it is unlikely that memory protection will >ever be implemented on AmigaDOS. I for one would gladely implement them as they >require no great engineering effort, but the god in the corner office is >unlikely to approve, for backward compatibility reasons. Plleeeeeeez? How about this... you PROVIDE software selectable memory protection - such that perhaps holding down a mouse button/key combination or something - invokes AmigaDOS 1.n with the memory protection, otherwise it runs rampant for "bass-ackwards" compatibility? ...by the way, who do we address the rotten tomatoes -- oops -- I mean the bribes to in the corner office? he he he. ;-) -Richard -- [ .signature under construction - turn back before it's too late ]
peter@sugar.hackercorp.com (Peter da Silva) (02/20/90)
The subject at hand is resource tracking. The question is who owns a resource. The problem is that on the Amiga ownership of a resource is a slippery thing. In article <22955@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: > Well, on the Amiga ALL system calls are done through libraries. Name me > one system call in graphics.library that is a "message". I don't think there's anything in graphics.library that's a system call. A shared library is a great thing, but it's still a shared library. It executes in the context (and the ownership) of the task currently executing. To actually do I/O, and in particular to perform input, you have to send messages around. You can use code in the libraries or you can build the packets and send the messages yourself. The result is the same... control over the ownership of the data changes. Turn to the front of your Rom Kernel Manual: Libraries and Devices. (I know you have one somewhere). Look at figure P-1. Virtually all of those little black lines are messages. Let's trace a typical system call. How about "read"? I think reading data from files is one of the top system calls. OK, you have this thing called a file handle. You can either use the code in dos.library or you can use Matt Dillon's asynchronous I/O routines or you can cut them yourselves. But what you actually *do* is send a packet to another task... the file system... asking for some data. If the file system has the data, it replies to your message. Otherwise it sends a message to another task... trackdisk.device, say... and when it gets a response sends the block back to you. And that's a simple call. How about tracing the path of a read from console.device with a couple of input handlers installed? But you know all this. In UNIX this sort of stuff is the exception. You make a read() system call, and enter kernel mode. Your process, your execution context, follows that block of data all the way down to the oxide and back. So... back to the point. On UNIX IPC is an exception. On the Amiga it's the rule. You can't have an Amiga program that doesn't do it. So resource tracking is a harder job. Which is all I said. You know all this. I know you know. You know I know this stuff as well. And I know you know. You know I know you know. And so on. So what's the problem? -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ I haven't lost my mind, it's backed up on tape somewhere! v "Have you hugged your wolf today?" `-_-'
papa@pollux.usc.edu (Marco Papa) (02/20/90)
In article <5185@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <22955@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >> Well, on the Amiga ALL system calls are done through libraries. Name me >> one system call in graphics.library that is a "message". > >I don't think there's anything in graphics.library that's a system call. A >shared library is a great thing, but it's still a shared library. It executes >in the context (and the ownership) of the task currently executing. To >actually do I/O, and in particular to perform input, you have to send messages >around. I guess we have different ideas of what a "system" call is. Is writing to the screen "doing I/O"? I think so. I call it OUTPUT :-) You don't seem to think that . UNIX, to take the example from which you've derived the use of "system calls", has open, close, read, write and ioctl (and mods of that). To write to the display on UNIX, you'd probably end up doing read/writes and a bunch of adapter specific ioctls. Are those system calls? I thinks so. On the Amiga, to do the same you call routines in graphics.library (or layer.library). As far as I know, these don't involve message passing of any kind. They invoke ROM kernel routines directly (pretty much like an adapter/specific ioctl would do). Are these "system" calls? I think so. You don't. Who cares? Look at the Amiga System Software modules picture in the RKMs. Graphics, audio, keyboard, mouse, etc. all talk directly to the hardware. None of their specific system calls for DOING I/O (most of them in ROM, since some of these libraries are ROM libraries, and they are just the same as adapter firmware or microcode on differernt platforms) involve message passing. So IMHO, the statement that "all system calls in the Amiga involve message passing is pure b.s.". The discussion is stale (i.e "what is the meaning of system call?"). Next topic, please. Have fun and enjoy the universe. -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
tron1@tronsbox.UUCP (HIM) (02/21/90)
>>In article <9704@cbmvax.commodore.com> valentin@cbmvax.cbm.commodore.com >>(Valentin Pepelea) writes: >> >>> Whoa! Come on, you know better than that! I can name a huge number of >>system >>> calls which do not end up send a message somewhere else. In fact, I have >>> a lot of difficulty identifying the calls which actually do send a message. >>> They're pretty rare. >> Ahem, I would say that all keyboard, i/o and disk access are message based that the majority of amiga system USAGE is IPC. As far as number of calls that EXIST , ypu may be right , but in how many are commonly DONE --- mostly IPC. **************************************************************************** Everything I say is Copr. 1990, except the stuff I stole from someone else and the stuff I don't want responsibility for. Kenneth J. Jamieson: Xanadu Enterprises Inc. "Professional Amiga Software" UUCP: tron1@tronsbox.UUCP BEST PATH ---> uunet!tronsbox!tron1 Sysop, Romantic Encounters BBS - (201)759-8450 / (201)759-8568 ****************************************************************************
peter@sugar.hackercorp.com (Peter da Silva) (02/22/90)
Look, the point isn't what a system call is or is not. The point is that apart
from the single special case of writing to the screen, every I/O (including
reading from the mouse or keyboard) involves messages. And the screen output
stuff also involves massive amounts of shared data.
Which UNIX doesn't bother the program with. It's a fundamental difference in
O/S philosophy. And it makes resource tracking on the Amiga a much more complex
problem. OK?
--
_--_|\ Peter da Silva <peter@sugar.hackercorp.com>.
/ \
\_.--._/ I haven't lost my mind, it's backed up on tape somewhere!
v "Have you hugged your wolf today?" `-_-'usenet@cps3xx.UUCP (Usenet file owner) (02/22/90)
In article <1990Feb19.125050.9380@stb.uucp> richard@stb.uucp (Richard Conner) writes: >In article <9716@cbmvax.commodore.com> valentin@cbmvax.cbm.commodore.com (Valentin Pepelea) writes: >>In article <131188@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >>>Something I personally would like to see would be a "runprotected" command >>>that would start a program and setfunction the appropriate vectors so that >>>the program would run with the MMU protecting all addresses outside of it's >>>range. YES! YES! YES! Me, too! [...] >> If the request provided is scrambled, a crash will occur under the >>device's context. > >I can live with that... Me, too! [...] >>Both these changes would cause some programs to fail, if implemented. So for >>backwards compatibility reasons, it is unlikely that memory protection will >>ever be implemented on AmigaDOS. I for one would gladely implement them as they [...] >Plleeeeeeez? How about this... you PROVIDE software selectable memory >protection - such that perhaps holding down a mouse button/key combination >or something - invokes AmigaDOS 1.n with the memory protection, otherwise >it runs rampant for "bass-ackwards" compatibility? [...] >-Richard [...] [desperate plea on] Some of us see the memory protection stuff as EXTREMELY useful. I would prefer an operating system that protects us from POORLY WRITTEN PROGRAMS! That way, many programs can be used with some assuredly that if they are poorly written and misbehaved that they won't mess up any other processes. I love the core dumps on the Sun workstations here at the University. They let you know if a program is a misbehaving without any damage to other processes. I'm sure some day I will be programming while having all sorts of other tasks running in the background. I know that I don't always get a program right the first time, so if my operating system doesn't take care of my mistakes, the other things running will not necessarily be kept secure. So therefore the usefulness of having a multitasking system will be minimized. [desperate plea off] _ /| \`o.O' Chris Dailey, Amiga Enthusiast =(___)= dailey@cpsin.cps.msu.edu U - "Meow." (Bill the Cat not original--imitation intended as a form of flattery.)
deven@rpi.edu (Deven T. Corzine) (02/23/90)
On 22 Feb 90 02:09:34 GMT, peter@sugar.hackercorp.com (Peter da Silva) said: Peter> Look, the point isn't what a system call is or is not. The Peter> point is that apart from the single special case of writing to Peter> the screen, every I/O (including reading from the mouse or Peter> keyboard) involves messages. And the screen output stuff also Peter> involves massive amounts of shared data. Consider. A system call does not HAVE to be I/O. Yes, all I/O to Exec devices and AmigaDOS filesystems involves message passing. Not all _system_ calls do. Does AddTask() use messages? No. Don't try telling me it's not a system call. Peter> Which UNIX doesn't bother the program with. It's a fundamental Peter> difference in O/S philosophy. And it makes resource tracking on Peter> the Amiga a much more complex problem. OK? More complex, yet if you intercept at the message-passing level, you're in the clear... (largely) 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.
himacdonald@watdragon.waterloo.edu (Hamish Macdonald) (02/23/90)
>>>>> On 22 Feb 90 19:11:10 GMT, deven@rpi.edu (Deven T. Corzine) said:
Deven> On 22 Feb 90 02:09:34 GMT, peter@sugar.hackercorp.com (Peter da
Deven> Silva) said:
Peter> Look, the point isn't what a system call is or is not. The
Peter> point is that apart from the single special case of writing to
Peter> the screen, every I/O (including reading from the mouse or
Peter> keyboard) involves messages. And the screen output stuff also
Peter> involves massive amounts of shared data.
Deven> Consider. A system call does not HAVE to be I/O. Yes, all I/O
Deven> to Exec devices and AmigaDOS filesystems involves message
Deven> passing. Not all _system_ calls do. Does AddTask() use
Deven> messages? No. Don't try telling me it's not a system call.
Question: Does I/O to Exec devices HAVE to involve message passing?
I don't believe so. When I do a 'who' on the Amiga here, it tells me
that I have an 'input.device' task running, and a couple of
'trackdisk.device' tasks running, and a number of others. Nowhere do
I see a 'serial.device' task (or anything remotely interpretable as
such) running. Since I am talking through VLT at the moment, I am
sure that the serial.device Exec device is in use.
I believe that access to the serial.device can be made in the context
of the process (or task) accessing it, and no messages need be sent
to/from a special serial.device process.
Comments?
Hamish.
--
--------------------------------------------------------------------
watmath!watdragon!himacdonald himacdonald@watdragon.waterloo.edu
"Guns seldom solve any problems; they merely decide whose will shall
prevail for the time being." - Brian Jarvisnew@udel.edu (Darren New) (02/23/90)
In article <21183@watdragon.waterloo.edu> himacdonald@watdragon.waterloo.edu (Hamish Macdonald) writes: >Question: Does I/O to Exec devices HAVE to involve message passing? >Nowhere do >I see a 'serial.device' task (or anything remotely interpretable as >such) running. Well, when I use XOper to look at the ports list, I see a serial.device message port generating a software interrupt into a serial.device task. It seems to me that if you can do asynchronous calls (like post a read and then write or wait for a timeout or ...) then you must be using messages. -- Darren
himacdonald@watdragon.waterloo.edu (Hamish Macdonald) (02/23/90)
>>>>> On 22 Feb 90 23:55:15 GMT, new@udel.edu (Darren New) said: Darren> In article <21183@watdragon.waterloo.edu> Darren> himacdonald@watdragon.waterloo.edu (Hamish Macdonald) writes: >Question: Does I/O to Exec devices HAVE to involve message passing? >Nowhere do >I see a 'serial.device' task (or anything remotely interpretable as >such) running. Darren> Well, when I use XOper to look at the ports list, I see a serial.device Darren> message port generating a software interrupt into a serial.device task. Darren> It seems to me that if you can do asynchronous calls (like post a read Darren> and then write or wait for a timeout or ...) then you must be using Darren> messages. -- Darren Fair enough. I wanted to try XOper as well, but couldn't find it anywhere on my friend's hard disk. Odd that 'who' didn't pick up that task. Perhaps it only lists processes. Hamish. -- -------------------------------------------------------------------- watmath!watdragon!himacdonald himacdonald@watdragon.waterloo.edu "Guns seldom solve any problems; they merely decide whose will shall prevail for the time being." - Brian Jarvis
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (02/23/90)
[ rn couldn't deal with all the references, so this is a brand new, reference free message. Sorry, broken software. ] himacdonald@watdragon.waterloo.edu (Hamish Macdonald) writes: >Question: Does I/O to Exec devices HAVE to involve message passing? >Nowhere do >I see a 'serial.device' task (or anything remotely interpretable as >such) running. new@udel.edu (Darren New) said: Darren> Well, when I use XOper to look at the ports list, I see a serial.device Darren> message port generating a software interrupt into a serial.device task. Darren> It seems to me that if you can do asynchronous calls (like post a read Darren> and then write or wait for a timeout or ...) then you must be using Darren> messages. -- Darren There's certainly a message port and a soft interrupt, but I don't see a task. I believe serial.device does all its work out of the soft interrupt on the message port, and a soft interrupt generated by the hardware interrupts on the serial port hardware. Serial.device doesn't do all that much, so it doesn't need a task, but you still send messages to it and it does not run in your context. -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University
mikalsen@bono.uucp (Thomas Mikalsen) (02/24/90)
- Thomas A. Mikalsen "The gold is for us to capture all we want." Rochester Institute of Technology -
mikalsen@bono.uucp (Thomas Mikalsen) (02/24/90)
Last spring I took the Operating System Lab class here at RIT. In the class we broke up into groups of 3-5 and wrote a multi-tasking O.S. on Sun-2s. One of the big questions was: do we do it kernal based or use message passing. Well, being an Amiga owner, and knowing some of the advantages to message passing, I liked the idea. But, since a kernal based os is easier to write (we had only 10 weeks) we went with the KERNAL. So what's my point?? Well, I wrote the windowing system for our OS. It COULD NOT be done in the kernal(loose to many interrupts). So we added some simple IPC. The window system was just another task running (with certain privileges.) A call to the window-system invloved a stub (that ran in user context) that sent the message to the window system. A kernal-call, on the other hand, involved a stub as well, but it trap-ed into supervisor mode and executed KERNAL code. Both calls are "system-calls" if you consider the windowing part of "The System." Defining what your system is defines what a system call is. Maybe kernal-call is what some people mean by system call. The term system-call describes the function of the call, NOT the method of passing parameters. This is just my opinion of course. The big plus of message-passing and shared libraries is that parts of the "system" can be added and modified with out having to re-make the kernal (so long as there is a sufficent interface built into the kernal already.) Tom. - Thomas A. Mikalsen "The gold is for us to capture all we want." Rochester Institute of Technology -
gilgalad@dip.eecs.umich.edu (Ralph Seguin) (02/24/90)
In article <315@spot.wbst128.xerox.com> mikalsen@bono.UUCP (Thomas Mikalsen) writes: >Last spring I took the Operating System Lab class here at RIT. In the >class we broke up into groups of 3-5 and wrote a multi-tasking O.S. >on Sun-2s. One of the big questions was: do we do it kernal based or >use message passing. Well, being an Amiga owner, and knowing some of >the advantages to message passing, I liked the idea. But, since >a kernal based os is easier to write (we had only 10 weeks) we >went with the KERNAL. > What you are describing is the difference between a heavyweight process system and a lightweight process system. In most heavyweight (ie, most UNIX systems), system, everything is in the kernel. IPC messaging is done by the kernel since it is the only thing allowed to map into the various address spaces without blowing up. The bad things about heavyweight kernels is that they are difficult to change, and sadly, everything, I mean everything, gets stuck down into the kernel (ie, huge kernel). This makes things difficult to deal with. If somebody wanted to make changes, to just the filesystem, then he would have to go and fiddle with the whole kernel , thereby leaving him/herself open to unwanted side effects. In a lightweight process system (MACH, Exec, QuickSilver, etc), it should be relatively easy to make changes to filesystem code, since it is just another process being run outside of the kernel. One other advantage of this is that if the filesystem crashes, it probably won't bring the whole system down, so you can restart the filesystem. Basically a lightweight process system allows multiple execution threads within the same address space, and has the file system and memory management out of the kernel as processes. An attempt is made to minimize the kernel, by just making it handle context switches, messaging and other things that absolutely have to go in there. In a heavyweight process system, you are only allowed one execution point per address space (although you can use coroutines or other such niceties if you want). Everything is placed into the kernel. I love the Amiga's IPC method: nonreplicating messages. Why on earth others haven't seen the wisdom in this is beyond me. Actually, people are starting to catch on. As to what is a kernel call, I'd say that anything to Exec() is a kernel call, since it is really the kernel. Everthing else is just tacked on top. Of course, this doesn't make for a useable system, so in reality, I'd say that a kernel call is anything to any of the libraries. What's a KERNAL anyways? (don't mind me, I'm just being a smart ass). >Tom. >- >Thomas A. Mikalsen "The gold is for us to capture all we want." >Rochester Institute of Technology >- Ralph gilgalad@caen.engin.umich.edu gilgalad@dip.eecs.umich.edu gilgalad@goliath.eecs.umich.edu Ralph_Seguin@ub.cc.umich.edu gilgalad@sparky.eecs.umich.edu USER6TUN@UMICHUB.BITNET Ralph Seguin | In order to get infinitely many monkeys to type 11010 Lighthouse Dr. #234 | something that actually makes sense, you need to Belleville, MI 48111 | have infinitely many monkey editors as well. (313) 697-1048
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (02/25/90)
In <5201@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) writes: >> Consider. A system call does not HAVE to be I/O. Yes, all I/O to >> Exec devices and AmigaDOS filesystems involves message passing. Not >> all _system_ calls do. Does AddTask() use messages? No. Don't try >> telling me it's not a system call. > >Argh... > >OK, let's put it this way. Come up with a program that does soemthing useful >and doesn't do any IPC at all. About the only thing I can think off is one >that runs ONLY under the CLI, has no diagnostic messages, and toggles the 7kHz >filter on and off (or does some other trivial hardware hackery (or hijackery)). Rather depends on what you mean by a system call and IPC doesn't it? The programmer need not concern himself that IPC is happening as the result of a system call, nor does he need to handle messages just because the system is using them behind his back. >IPC is integral to the Amiga. Sharing memory between a bunch of tasks is not >something you can get away from. It's rare on UNIX. That I'll go along with. >Maybe I need a disclaimer: "If this message uses different magic incantations >than the ones you're used to, try to see if that effects the content before >flaming"? Perhaps so.. a system call is a system call. That it generates a message or a series of messages is beside the point. Perhaps you'd enlighten us with your definition of 'system call'. -larry -- Gallium Arsenide is the technology of the future; always has been, always will be. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
peter@sugar.hackercorp.com (Peter da Silva) (02/25/90)
> Consider. A system call does not HAVE to be I/O. Yes, all I/O to > Exec devices and AmigaDOS filesystems involves message passing. Not > all _system_ calls do. Does AddTask() use messages? No. Don't try > telling me it's not a system call. Argh... OK, let's put it this way. Come up with a program that does soemthing useful and doesn't do any IPC at all. About the only thing I can think off is one that runs ONLY under the CLI, has no diagnostic messages, and toggles the 7kHz filter on and off (or does some other trivial hardware hackery (or hijackery)). IPC is integral to the Amiga. Sharing memory between a bunch of tasks is not something you can get away from. It's rare on UNIX. Maybe I need a disclaimer: "If this message uses different magic incantations than the ones you're used to, try to see if that effects the content before flaming"? -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ I haven't lost my mind, it's backed up on tape somewhere! v "Have you hugged your wolf today?" `-_-'
deven@rpi.edu (Deven T. Corzine) (02/26/90)
On 25 Feb 90 05:33:44 GMT, peter@sugar.hackercorp.com (Peter da Silva) said: Peter> OK, let's put it this way. Come up with a program that does Peter> soemthing useful and doesn't do any IPC at all. About the only Peter> thing I can think off is one that runs ONLY under the CLI, has Peter> no diagnostic messages, and toggles the 7kHz filter on and off Peter> (or does some other trivial hardware hackery (or hijackery)). Ah, but you see, I never claimed you could do anything useful on the Amiga without using messge passing at some level or another. I objected to your generalization that all system calls involve message passing. As with AddTask(), that is simply untrue. On the other hand, in general no program can do much of use without doing some I/O, which DOES involve message passing. Peter> IPC is integral to the Amiga. Sharing memory between a bunch of Peter> tasks is not something you can get away from. It's rare on Peter> UNIX. Yes, the Amiga depends on shared memory for operation, and it makes resource tracking dangerous. But, if you keep track of what messages have been sent but not replied to, then message passing can be tracked. (You would, of course, need _something_ to hang around waiting for the message before deallocating it, but it can be done.) Peter> Maybe I need a disclaimer: "If this message uses different Peter> magic incantations than the ones you're used to, try to see if Peter> that effects the content before flaming"? "affects". ;-) 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.
peter@sugar.hackercorp.com (Peter da Silva) (02/26/90)
> Ah, but you see, I never claimed you could do anything useful on the > Amiga without using messge passing at some level or another. I > objected to your generalization that all system calls involve message > passing. As with AddTask(), that is simply untrue. True or not, it's simply irrelevant. Haven't you ever heard of rhetorical effect? Don't you know that 2+2=3, for sufficiently large values of 3? Disclaimer: this article will self-destruct in 30 seconds. -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ I haven't lost my mind, it's backed up on tape somewhere! v "Have you hugged your wolf today?" `-_-'
new@udel.edu (Darren New) (02/27/90)
In article <1543@zipeecs.umich.edu> gilgalad@eecs.umich.edu (Ralph Seguin) writes: >I love the Amiga's IPC method: nonreplicating messages. Why on earth others >haven't seen the wisdom in this is beyond me. Actually, people are starting >to catch on. I've been trying to think of a clean way to allow a multi-user version of this kind of thing. Somethink like having each field of a message being tagged with flags saying whether it was to be interpreted as an address and if so, whether it may be read and/or written by the receiver. If you have come up with (or seen) a clean solution, please let me know. Maybe segments a la Multics? >What's a KERNAL anyways? (don't mind me, I'm just being a smart ass). I always thought it was the part you couldn't replace without being privledged. Hence, on a single user micro, there IS no kernal (kernel?) just libraries. -- Darren
papa@pollux.usc.edu (Marco Papa) (02/27/90)
In article <5207@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >> I objected to your generalization that all system calls involve message >> passing. As with AddTask(), that is simply untrue. > >True or not, it's simply irrelevant. Haven't you ever heard of rhetorical >effect? Don't you know that 2+2=3, for sufficiently large values of 3? By continuing to not even move one inch from his statements that "all systems calls on the Amiga involve message passing", after an overwhelming numer of people tried to convince him that HIS generalization doesn't apply, Peter has shown that he has the brain of a 5-year old, that can't even admit when he f***s up. Arguments like the one above (note, no smileys), are the food of spoiled brats. Grow up, dude. >Disclaimer: this article will self-destruct in 30 seconds. I wish :-) -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
deven@rpi.edu (Deven T. Corzine) (02/27/90)
On 26 Feb 90 13:42:35 GMT, peter@sugar.hackercorp.com (Peter da Silva) said: Peter> True or not, it's simply irrelevant. Haven't you ever heard of Peter> rhetorical effect? Don't you know that 2+2=3, for sufficiently Peter> large values of 3? Actually, I prefer "2+2=5 for large values of 2." :-) 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.
peter@sugar.hackercorp.com (Peter da Silva) (02/27/90)
In article <1165@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: > Rather depends on what you mean by a system call and IPC doesn't it? The > programmer need not concern himself that IPC is happening as the result of a > system call, nor does he need to handle messages just because the system is > using them behind his back. (hyperventilating) We're not talking about what the programmer sees. (calmer) Or at least I'm not. The point is what the system sees. All that IPC makes resource tracking a harder problem than it is in UNIX. When a program exits, the system really has no way of knowing whether it can safely free any resources allocated by that program or not. > Perhaps so.. a system call is a system call. That it generates a message or a > series of messages is beside the point. No, that it generates a series of messages or otherwise has to coordinate with other processes is *precisely* the point. Even line drawing, through the layers library, has to be co-ordinated... -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ I haven't lost my mind, it's backed up on tape somewhere! v "Have you hugged your wolf today?" `-_-'
peter@sugar.hackercorp.com (Peter da Silva) (02/27/90)
In article <23088@usc.edu> papa@pollux.usc.edu (Marco Papa) flames for
a while....
Thank you very much. I'm not refusing to move anywhere. I've acknowledged
that my terminology was incorrect. What I don't see is what relevence that
has to what I was trying to say... which is that virtually anything you do
on the Amiga involves inteprocess communication and sharing resources with
other tasks. If you (the collective you) would quit being such LMIs and
consider the substance of what I'm saying here perhaps we'd make some
progress.
I'm totally dumbfounded at the reaction that a single poorly-worded sentence
has produced from what I believe to be a generally sensible bunch of folks.
I hereby completely retract anything I have said that might even imply that
the phrase "system call" has any relevance to the Amiga, or that message
passing is the only form of interprocess communication. I retract these
statements without any caveats or exceptions. Now can we get on with some
productive work instead?
--
_--_|\ Peter da Silva <peter@sugar.hackercorp.com>.
/ \
\_.--._/ I haven't lost my mind, it's backed up on tape somewhere!
v "Have you hugged your wolf today?" `-_-'doug@xdos.UUCP (Doug Merritt) (02/28/90)
In article <23088@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >In article <5207@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >>True or not, it's simply irrelevant. Haven't you ever heard of rhetorical >>effect? Don't you know that 2+2=3, for sufficiently large values of 3? > >apply, Peter has shown that he has the brain of a 5-year old, that can't >even admit when he f***s up. Arguments like the one above (note, no >smileys), are the food of spoiled brats. > >Grow up, dude. Arguments like this are tedious and unconstructive to start with, but this flame is uncalled for. Marco, Peter may be wrong (who really cares, though? What's in a word?), but *you* are just being plain rude. Comments like that simply make us innocent bystanders think that perhaps this is a case of "the pot calling the kettle black". I'm surprised you have the balls to post something that reflects as badly on you as this does. Have you no shame? It wouldn't hurt for both of you to make peace and get back to business as usual. We're professionals, right?? Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
papa@pollux.usc.edu (Marco Papa) (02/28/90)
In article <5215@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <23088@usc.edu> papa@pollux.usc.edu (Marco Papa) flames for >I hereby completely retract anything I have said that might even imply that >the phrase "system call" has any relevance to the Amiga, or that message >passing is the only form of interprocess communication. I retract these >statements without any caveats or exceptions. Now can we get on with some >productive work instead? Absolutely. -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
papa@pollux.usc.edu (Marco Papa) (02/28/90)
In article <5214@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >(calmer) Or at least I'm not. The point is what the system sees. All that >IPC makes resource tracking a harder problem than it is in UNIX. When a program >exits, the system really has no way of knowing whether it can safely free >any resources allocated by that program or not. I am not sure that the problem lies in the fact that IPC is done with messages or not. Take another system, for example, MS-Windows DDE (Dynamic Data Exchange). There, messages are "global memory" ATOMS that are passed around. The DDE protocol states who can and who cannot free these atom after they've been used, and the situation is always deterministic (a message sender can tell the receiver to "free" the message after having used it, or ACK it back for freeing by the sender). So, IMHO it is not the "method" that might be faulty, but the implementation. -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
papa@pollux.usc.edu (Marco Papa) (02/28/90)
In article <672@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes: [Argument omitted] >Arguments like this are tedious and unconstructive to start with, >but this flame is uncalled for. Marco, Peter may be wrong (who really >cares, though? What's in a word?), but *you* are just being plain >rude. Yes, I definitely got carried away. I should consult more often the Usenet Etiquette Bible ("don't post when drunk, stoned, or angry with your boss" :-) -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
peter@sugar.hackercorp.com (Peter da Silva) (02/28/90)
> I am not sure that the problem lies in the fact that IPC is done with > messages or not. No, it doesn't matter if IPC is done with postcards or post office boxes, either. It complicates things whatever way you do it. MS Windows is widely regarded as an incredibly hard environment to program in (I just saw a joke on the net: "What's bigger than Hello World in X?" "Hello World in Microsoft Windows!"). There are better examples of safe message passing systems... Mach being a good example. > it is not the "method" that might be faulty, but the implementation. A better implementation is certainly possible, but it's still a hard problem. Going back to post office boxes, there are thousands of unclaimed PO boxes ever year, as well as bank accounts and so on. It's a hard problem in the real world as well... -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ I haven't lost my mind, it's backed up on tape somewhere! v "Have you hugged your wolf today?" `-_-'
panon@cheddar.cc.ubc.ca (Paul-Andre Panon) (03/01/90)
In article <1165@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >Rather depends on what you mean by a system call and IPC doesn't it? The >programmer need not concern himself that IPC is happening as the result of a >system call, nor does he need to handle messages just because the system is >using them behind his back. > >>IPC is integral to the Amiga. Sharing memory between a bunch of tasks is not >>something you can get away from. It's rare on UNIX. > >That I'll go along with. > >-larry I think you lost the context of the thread, Larry. The idea was that, for most system calls on the Amiga, one or more messages will wind up being passed somewhere in the processing of that call. This is certainly true in the case of most filesystem or device I/O. Which means that, unlike what was stated in another message by somebody else (Peter?) a CLI doesn't qualify. It uses dos's CON: handler, thus the console.device, IDCMP messages, and at the lowest level, input.device. Probably most of these will generate messages when the device process has "locked" device globals (although the code may be executed in the calling process' context occasionally; if the RKM:L&D device format is the used in the device, BeginIO only generates a message to the device process to queue the command if another command is already in progress). To guarantee that you would do no message passing, you would probably have to: -Bypass intuition by building your own View and use the layers library (optional if you don't want windows) and the graphics library for output, - I'm not sure whether you could do input without at least one call/message to the input.device to shut it down so you can take over, - NOT do any "file" I/O, not even trackdisk.device! Now, the first condition is generally pretty amiga unfriendly. Maybe you wouldn't have to go quite so far if OpenScreen() doesn't actually send a message - this is probably the case since it probably does stuff by locking IBase; you could then do output into the screen's rastport and even use layers without IPC. However, I seem to remember from stuff posted here that the structure of intuition is one of the things which undergoes major changes in 1.4 so it may be impossible to OpenScreen() without using IPC under 1.4. Limiting your program to doing output kind of cuts down on the classes of program you can have. Interestingly enough, most arcade-type game programs can meet those requirements (once loaded) since I've gotten the impression you can get input from the second port in an "amiga-friendly" manner without going through the input.device, ie. at the resource level. It wouldn't be very clean though, would it? So you probably can get a fair amount done without IPC on the Amiga if you go to a sufficiently low level, but most of the higher level libraries do use IPC. You would lose most of the Amiga's UI capabilities if you limited yourself to non-IPC functions. This, I, think is probably what the original author had in mind when this thread started and he said (paraphrased) that most Amiga function calls used IPC. -- Paul-Andre_Panon@cheddar.cc.ubc.ca or USERPAP1@UBCMTSG or Paul-Andre_Panon@undergrad.cs.ubc.ca or USERPAP1@mtsg.ubc.ca "What should the role of the University be? It should be to enlighten Society." -Luis Sobrino
FelineGrace@cup.portal.com (Dana B Bourgeois) (03/01/90)
[nope, no line eater here] I just spent ten minutes paging through all this stuff! I suggest (only slightly tongue-in-cheek) we start a new thread called: Comp/sys/amiga.philosophy It would be for all those tedious, academic, boring, sometimes sophomoric discussions about whether the world is flat, what happens when you fall off the resulting edge, and how many systems administrators can dance on the head of a pin. At least try to see the other guys point and acknowledge it. I don't believe I am the only one who gets tired of hitting 'next' while articles defining semantics go scrolling by. Let's facilitate communication and not put up roadblocks. Thank you for sharing. Dana Bourgeois @ cup.portal.com
ccplumb@lion.waterloo.edu (Colin Plumb) (03/02/90)
In article <22955@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >Well, on the Amiga ALL system calls are done through libraries. Name me >one system call in graphics.library that is a "message". Or even take >exec.library or dos.library. Get your facts, Peter. Generalizing (i.e. >using attibutes like "all") without checking it out often results in >making dumb statements like the one above. True, there are a lot of things which are calls. But dos.library is a wrapper around packet sending. A read() call involves at least two message sends, one from your process (via dos.library) to the device handler, and one (or possibly many) thence to the exec .device driver. Intuition also flings a lot of messages around. Exec.library, of course, implements the message sending and so can't be based on message sending itself. -- -Colin