home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / atari / st / tech / 6320 < prev    next >
Encoding:
Text File  |  1992-12-17  |  2.2 KB  |  52 lines
  1. Newsgroups: comp.sys.atari.st.tech
  2. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!umn.edu!csus.edu!netcom.com!ersmith
  3. From: ersmith@netcom.com (Eric R. Smith)
  4. Subject: Re: XBRA and Memory Protection.
  5. Message-ID: <1992Dec17.184658.3300@netcom.com>
  6. Organization: Netcom Online Communications Services (408-241-9760 login: guest)
  7. References: <memo.814282@cix.compulink.co.uk>
  8. Date: Thu, 17 Dec 1992 18:46:58 GMT
  9. Lines: 41
  10.  
  11. In article <memo.814282@cix.compulink.co.uk> apelled@cix.compulink.co.uk writes:
  12. >>From: Roine Stenberg
  13. >>To  : Adam Pelled
  14. >>Subj: Re: Xbra on MultiTOS ?
  15.  
  16. >>If i want to follow a XBRA structure, i MUST peek inside EVERY program in 
  17. >>the XBRA list.
  18. >>With MultiTOS/68030 programs will have memory protection, and if my program 
  19. >>tries to look into some other programs occupied memory, the MMU of the 
  20. >>68030 will generate a BUS ERROR to my program.
  21.  
  22. >    i have been informed that this has to be done in supervisor mode.
  23. >What do the panel think ?
  24.  
  25. Of course it has to be done in supervisor mode, since most of the interrupt
  26. vectors are in locations that are only accessible in supervisor mode.
  27.  
  28. Doing it in supervisor mode solves another problem, too: any program
  29. that changes an interrupt vector must make its memory accessible to
  30. any other program that is in supervisor mode, since otherwise
  31. the interrupt will cause a bus error. Hence, you know that you can
  32. indeed read another program's XBRA structure, as long as you are in
  33. super mode.
  34.  
  35. NOTES: (1) Avoid trapping into interrupt vectors. If you don't grab
  36. vectors, you don't need XBRA, and the whole thing becomes much easier.
  37. MultiTOS provides a variety of ways to do things without grabbing
  38. vectors; you can even write a debugger that doesn't grab vectors!
  39.  
  40. (2) If you can't do (1), then use Setexc() to change vectors. If you
  41. do, then MultiTOS will automatically grant supervisor access to other
  42. processes for the memory the vector points to, and everything will
  43. work transparently.
  44.  
  45. (3) If you don't do (2), users will have to run a utility to change
  46. your program's flags so that it will not be protected against supervisor
  47. access. Users won't like having to do this. So use Setexc(), that's
  48. why it's in the operating system!
  49.  
  50. Regards,
  51. Eric
  52.