davidj@brad.inmos.co.uk (David Johnston) (05/18/91)
I have an SCF device driver which serves an IMS B014
VME transputer slave board from a VME based 68k os9
system. This works correctly, with the appropriate
interrupt routines. However due to the single character
nature of SCF drivers, the data transfer rate is a
pitifull 30k/second.
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
possible on the B014 (400k/sec).
Without interrupts, this scheme functions, but when
I introduce code to timeout and wait on an interrupt
the whole this falls over.
It appears that the V_BUSY location in the static
storage area is set to 0 on entry to the device driver,
and so the IRQ service routine fails to recieve the
process ID of the routine which called F$SLEEP.
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.
Can any OS9 guru's tell me what I am meant to be
doing & whether I've grasped anything approaching the
correct end of the stick?
Both the driver and the filemanager are written in
68020 machine code.
Thanks,
Dave
:+-+:+-+:+-+:+-+:+-+:+-+:+-+:+-+:+-+:+-+:+-+:+-+:+-+:+-+:+-+:+-+:+-+:+-+:+-+:
David Johnston, INMOS Ltd,1000 Aztec West, Almondsbury,Bristol, BS12 4SQ, UK.
JANET: davidj@uk.co.inmos INET: davidj@inmos.com TEL: +44 454 616616
UUCP: ..{ukc!inmos,uunet!inmos-c}!davidj FAX: +44 454 617910kdarling@hobbes.catt.ncsu.edu (Kevin Darling) (05/19/91)
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 <kdarling@catt.ncsu.edu>
dibble@mcrware.UUCP (Peter Dibble) (05/21/91)
davidj@brad.inmos.co.uk (David Johnston) writes: > [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. See the last few lines on page 311 of "Insights." It's not what you'd call a clear and detailed discussion, but it does show you the standard OS-9 way for file managers to handle V_BUSY. <This brings up a bug in the book's PCFM code. PCFM should do the IOQ/V_BUSY stuff for setstat calls. It doesn't.> Peter