martin@cs.uchicago.edu (01/23/91)
I'm unclear about the relationship between RAM DRVRs, resLocked, and
dNeedLock. Specifically:
Does a resLocked DRVR effectively have dNeedLock?
Does a dNeedLock DRVR effectively have resLocked?
Isn't a DRVR always locked anyway between OpenDriver and CloseDriver?
My hypotheses are: Yes, No (not necessarily locked before OpenDriver and
after CloseDriver), and Yes. Now for some examples:
The DRVR patches traps when opened and removes them when closed.
Use dNeedLock?
The DRVR patches traps when opened which remain when closed.
Use resLocked?
The DRVR does no patches.
Neither resLocked nor dNeedLocked are necessary?
What all this is getting at is, if the DRVR needs resLocked or dNeedLock,
how should it be handled so as to cause the least fragmentation to the
heap? I.e., after:
drvr := Get1Resource ('DRVR', id);
If the DRVR is resLocked, then its placement in the heap seems somewhat
random. Would a MoveHHi before locking have been appropriate?
Thanks for all advice.
Charles Martin // martin@cs.uchicago.eduresnick@cogsci.uiuc.edu (Pete Resnick) (01/23/91)
I think Charles gets this wrong. First let's see what's going on: A DRVR will be a handle to the code to be executed. This handle will be part of a record that the Device Manager keeps in the driver table. The code must *always* be locked when the code is being executed (how horrible it would be if executing code was moved in memory!!). Any time the a Device Manager call is made, either by a program or by the Device Manager itself with accRun, etc., the Device Manager will lock the handle. Any time the code finishes, the Device Manager will be the one to unlock it, unless you specifically tell it not to with dNeedLock. Why would you not want your code unlocked?? If your code can be called by other than the Device Manager, like a completion routine that you pass to something that will complete later. The Device Manager will have no warning to lock your code, so you have to tell it not to unlock it. So: martin@cs.uchicago.edu writes: >I'm unclear about the relationship between RAM DRVRs, resLocked, and >dNeedLock. Specifically: > Does a resLocked DRVR effectively have dNeedLock? > Does a dNeedLock DRVR effectively have resLocked? > Isn't a DRVR always locked anyway between OpenDriver and CloseDriver? >My hypotheses are: Yes, No (not necessarily locked before OpenDriver and >after CloseDriver), and Yes. Now for some examples: I think the answers should be no, no, and no. The Device Manager should, as I understand it, attempt to unlock your driver after exection unless you tell it specifically not to. The answer to the second question is correct; the driver should be locked between Open and Close. The answer to the third question is also no, as explained above. > The DRVR patches traps when opened and removes them when closed. > Use dNeedLock? > The DRVR patches traps when opened which remain when closed. > Use resLocked? > The DRVR does no patches. > Neither resLocked nor dNeedLocked are necessary? Depends on what you mean by patches traps. If you mean that the driver will load and lock *other* code to patch the traps, then no, it doesn't need lock. If the driver will have its *own code* as the patches, then clearly yes, since the patches may be called when the Device Manager doesn't have you locked. And again, even if there are no patches, if a driver routines can be called by something other than the Device Manager, you will need to lock it. >What all this is getting at is, if the DRVR needs resLocked or dNeedLock, >how should it be handled so as to cause the least fragmentation to the >heap? I.e., after: > drvr := Get1Resource ('DRVR', id); >If the DRVR is resLocked, then its placement in the heap seems somewhat >random. Would a MoveHHi before locking have been appropriate? Doesn't loading a locked resource automatically do a MoveHHi anyway? pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet/ARPAnet/EDUnet : resnick@cogsci.uiuc.edu BITNET (if no other way) : FREE0285@UIUCVMD
time@tbomb.ice.com (Tim Endres) (01/25/91)
In article <1991Jan22.230133.19377@midway.uchicago.edu>, martin@cs.uchicago.edu writes: > I'm unclear about the relationship between RAM DRVRs, resLocked, and > dNeedLock. Specifically: > > Does a resLocked DRVR effectively have dNeedLock? > Does a dNeedLock DRVR effectively have resLocked? > Isn't a DRVR always locked anyway between OpenDriver and CloseDriver? RAM drivers and ROM drivers have only one difference: RAM based drivers are expected to provide a HANDLE in the dCtlDriver field of the driver control entry. ROM based drivers are expected to provide a POINTER in the dCtlDriver field. The driver control entry field "dCtlFlags" RAM-Based bit determines whether or not the driver is RAM based (1) or not (0). As for the dNeedLock bit, if you are ROM based, set this bit. This tells the Device Mgr to not lock the driver code. If you are RAM based un-set this bit, so the Mgr knows to lock you down. This is not intuitive, and you have to read the comment on page II-188 very carefully. Don't worry about the ResLocked bit. tim. ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uupsi!ice.com!time 8840 Main Street | Whitmore Lake MI. 48189 | (313) 449 8288
stevec@Apple.COM (Steve Christensen) (01/26/91)
time@ice.com writes: >martin@cs.uchicago.edu writes: >> I'm unclear about the relationship between RAM DRVRs, resLocked, and >> dNeedLock. Specifically: >> >> Does a resLocked DRVR effectively have dNeedLock? >> Does a dNeedLock DRVR effectively have resLocked? >> Isn't a DRVR always locked anyway between OpenDriver and CloseDriver? > >RAM drivers and ROM drivers have only one difference: > RAM based drivers are expected to provide a HANDLE in the dCtlDriver > field of the driver control entry. ROM based drivers are expected > to provide a POINTER in the dCtlDriver field. > > The driver control entry field "dCtlFlags" RAM-Based bit determines > whether or not the driver is RAM based (1) or not (0). > > As for the dNeedLock bit, if you are ROM based, set this bit. > This tells the Device Mgr to not lock the driver code. If you > are RAM based un-set this bit, so the Mgr knows to lock you down. > This is not intuitive, and you have to read the comment on page > II-188 very carefully. > > Don't worry about the ResLocked bit. RAM-based drivers don't need to provide a handle, and could, in fact, live in the middle of a heap block--the Device Manager doesn't care. The RAM/ROM bit basically determines how to get to the start of the driver, i.e., if it needs to de-reference a handle or just use the pointer, and also whether or not it needs to lock the handle while in the middle of a call. If you specify your driver to be "RAM-based" (referenced by a handle), then the driver will be locked only when the Device Manager calls it (Open, Close, Control, Status, Prime), and the rest of the time it will float in the heap. If you set the dNeedLock bit, then the driver will be locked down as long as it's open. This is only needed if some portion of the driver is called by someone other than the Device Manager. Examples of this are VBL routines and trap patches. steve -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Steve Christensen | Apple Computer, Inc. | Disclaimer: | 20525 Mariani Ave, MS-81CS | the above may be stevec@apple.com | Cupertino, CA 95014 | a lie...or not.