dillon@CORY.BERKELEY.EDU (Matt Dillon) (06/13/87)
The DOS technical reference manual is seriously lacking of information required to implement device drivers. Can anybody tell me how to implement the following? (perry?): (from the device driver's point of view) ACTION_LOCATEOBJECT Arg1 is a Lock. Is this the home directory lock? What fields in the Lock structure must be filled in? ACTION_FREELOCK Do we FreeMem() the lock structure? Do we unlink the lock structure from the list? P.S. *ALL* the funcitons are poorly documented, the above two are simply a priority in my case. -Matt
hamilton@uxc.cso.uiuc.edu.UUCP (06/15/87)
dillon@CORY says: > The DOS technical reference manual is seriously lacking of information > required to implement device drivers. Can anybody tell me how to implement > the following? (perry?): > > (from the device driver's point of view) > > ACTION_LOCATEOBJECT > > Arg1 is a Lock. Is this the home directory lock? LOCATE takes as args a lock on a directory, a name to search that directory for, and the type of lock (exclusive or shared) desired. a DOS Open() causes a driver FIND{IN,OUT}PUT. the code to handle FIND* will use LOCATE to recursively lock all the dir's on the way to locking the final destination. [i'm mixing this up a bit, as if the driver sends packets to itself... but i think you know what i mean. when the user or DOS wants the driver to do something, it's a packet; when the driver does it itself, its an internal procedure call]. > What fields in the Lock structure must be filled in? since the lock is the property of the driver, it contains whatever the driver wants. disk locks differ from ram locks. i think even "RAM:" locks differ from "VDK:" locks. the user has to get his locks from the driver; in order to have a place to start, the null lock is recognised by the driver as a synonym for a lock on the root node. with this to start with, plus LOCATE and EXAMINE/EXNEXT, you can navigate anywhere. the user might read a lock, to get the volume-node pointer or the driver's port address, but should not be writing it. > ACTION_FREELOCK > > Do we FreeMem() the lock structure? yes; since we (the device driver) do the AllocMem() as well, it's only natural. > Do we unlink the lock structure from the list? we'd better... the LockList is our idea of what's locked. if we didn't unlink 'em, an exclusive lock would last forever. if we want to do consistency checks on lock args handed to us, we traverse the list to find the arg lock; if it ain't there, it's an invalid arg. this is off the top of my head, but it think it's correct. wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,seismo,pur-ee,convex}!uiucuxc!hamilton ARPA: hamilton@uxc.cso.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%uxc@uiuc.csnet Phone: (217)333-8703 CIS: [73047,544] PLink: w hamilton