> :>There are mechanisms for doing that which do not violate integrity. > Define what you mean by "integrity".
Integrity in this case means making sure you are looking at the address space you think you are looking at. Your definition (below) is only a part of the overall requirement. > I see integrity as preventing a problem state routine from doing something > malicious or outside it's box Yes. > and preventing a supervisor state routine from accidentally doing > something unexpected. This is getting close to the real point. You are asking help to write a supervisor state function to do something that is completely outside of the architecture. The instruction you wanted to use will do what you want, but without the protection of being wrapped in the operating system's service environment, there is a grave risk you will find yourself out in the weeds sooner or later. Make that a certainty. > I agree that there is a need to provide a means so that a supervisor state > routine does not unknowingly PT somewhere where integrity might be > violated, but I do see the need for the supervisor state routine to say > even though this PT appears to violate integrity - it does not - so let > me do it anyway. The instruction architecture (i.e. PoPs) allows a supervisor program to do a great many things whether they are "safe" or not. The operating system provides a software architecture in which those things can be done safely and reliably. The software architecture does not allow you to branch into some arbitrary address space, even though the hardware does allow it. There are good reasons for that and you haven't given any justification at all for ignoring them. > :>PT/PTI is the WRONG way to get primary addressability to another space. > > That is an opinion. > I hope you can accept that reasonable people can disagree. You may call it an opinion if you want, but you will find 100% of the IBM core technology design people agree with that opinion. (Right guys?) Reasonable people may very well disagree, but it would be unwise to disagree without understanding the reasons why the architecture is the way it is. > :>You have only two legal choices. Your can set up space-switch PC > :>services in the target address space and use a PC to get there, or you > :>can schedule an SRB. > > Yes, I am aware of the legal choices. > > The first one involves screwing around with the client address space so > that it might have bad effects, and the second is out of line. Here's where we get into really deep water. I described the two approved ways of getting addressability to another address space. The first one (PC services) is really only available to service providers. It would be irrational to go planting PC routines in random address spaces. If you are intent on "snooping" in any other address space than your own, then the one and only legal choice you have is to schedule an SRB into that space and snoop to your heart's content. There is NOTHING out of line about that. In fact, that is how most of the monitor products operate. > I tend to write supervisor state code carefully. It would take real bad > planning to end up with "a supervisor state PSW pointing to the ozone". It isn't a matter of how careful you are. There is nothing you or anyone else could do in a rational amount of code that would prevent these problems from occurring. Stop for just a moment and ask yourself why the cross memory services architecture is designed the way it is. I promise you it isn't just to frustrate would-be snoopers. CC ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
