Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!lll-winken!taco!hobbes.catt.ncsu.edu!kdarling From: kdarling@hobbes.catt.ncsu.edu (Kevin Darling) Newsgroups: comp.os.os9 Subject: Re: V_BUSY, who sets it? Keywords: filemanager V_BUSY Message-ID: <1991May18.203057.25113@ncsu.edu> Date: 18 May 91 20:30:57 GMT References: <16115@ganymede.inmos.co.uk> Sender: news@ncsu.edu (USENET News System) Organization: North Carolina State University Lines: 69 davidj@brad.inmos.co.uk (David Johnston) writes: > To get around this I wrote a string based filemanager, where > a buffer pointer and length value are passed to the device driver. > The driver is then able to send the whole buffer at a speed close > to the maximum speed [...] I hear OS-9000 can do something similar under its SCF... wish they'd port that back to OSK ;-). > [problem with IRQ routine and no V_Busy set] > This kind of indicates that the filemanager is responsible for > setting V_BUSY correctly, however none of my documemtation (Dibble, > OS9 manuals & I/O tech ref) gives information on which routine should > do this, or how. You're correct about the file manager (see Technical I/O Ref pg 1-23+... "Device Drivers That Control Multiple Devices" - Simple Devices subsection). It usually does the device blocking (the kernel does the main path blocking). Basically, a file manager would check to see if the device is busy or not -- if so, queue the process; otherwise set V_BUSY, call driver, clear V_BUSY. Two routines to grab and release a device might be: ******************************* * Grab Device - get ownership, set V_BUSY * (a1) = Path Descriptor * (a4) = Proc Descriptor * returns carry set if need to abort request * destroys d0,d1,a0 grab_device move.l PD_DEV(a1),a0 get device table pointer for path move.l V$STAT(a0),a0 a0=device static storage move.w V_BUSY(a0),d0 d0=current device owner beq.s got_device ...okay if no owner now! os9 F$IOQu else sleep us in I/O queue of current owner (d0.w) move.w P$Signal(a4),d1 Yawn, did kernel wake us with non-deadly signal? beq.s grab_device ..yes try again, might be our turn now ori #Carry,ccr else better give up (this is optional and rts may not be needed in your kind of mgr) got_device move.w PD_CPR(a1),V_BUSY(a0) set us as current device owner [copy other parms if wished (xon/xoff/pause/int/quit/lprc)] rts ******************************* * Release Device - clear V_BUSY * (a1) = Path Descriptor * destroys d0,a0 release_device move.l PD_DEV(a1),a0 get device table pointer for path move.l V$STAT(a0),a0 a0=device static storage move.w PD_CPR(a1),d0 d0=our proc id cmp.w V_BUSY(a0),d0 we current owner? (optional, depends on mgr flow) bne.s rel_rts ..nope clr.w V_BUSY(a0) yes we are, so release device rel_rts rts You can add lots of optional checking and/or copying of special path params as needed by your manager, of course. Perhaps even your own unqueuing with signals instead of waiting for the kernel to do it when a process returns from the file manager. Many possibilities. Luck! - kevin