>  I thought, as it's the kernel doing the polling that it would always
>be the 'forground' task.
>   I thought the kernel itself couldn't be preemptively multitasked in
>UNIX (at least not in NetBSD), so that when something sticks in the
>kerel, the whole machine hangs.

Yes it is the forground task.
Normally the I/O request is either queued (if xfer already in progress) or
started e.g. via bread() The function calling bread() is then likely to do a
biowait() to wait for the I/O to complete. If the I/O has not completed
biowait() will sleep allowing another process to be switched in and run.
When the I/O completes and the driver receives the IRQ it will call biodone()
to indicate that the I/O is complete. Any processes that were sleeping on the
I/O buffer will be woken and will be switched back in as per normal switching.

If you don't have IRQ's there the driver has no way to do the biodone()
callback and thus cannot return from the strategy routine until the I/O is
complete.
It then calls biodone() and returns. The caller will then call biowait() and
see that the I/O is complete.

Ok that is a very simplifed background to I/O ;-)
The SCSI driver is similar but there is an extra layer of code. The sd driver
will get the strategy requests from the kernel and will present SCSI xfer
requests to the actual SCSI driver. This performs the request and calls back
scsidone() when a xfer is complete.

In conclusion if you are polling then you are hanging up the rest of the
kernel.

There is no reason why polling the the kernel cannot be a similar speed to
RiscOS however you the polling routine can be interrupted so the poll speed
will be slowed down by other interrupts.

If I remember rightly, the sfasixfer() routine will read a byte, then poll
the status for the next next data ready flag etc.
the polling is done in sfasiwait() so for every byte you xfer you are calling
another function, pushing a stack frame etc. as it is all in C.

The iwait and ixfer routines are generic and were not written to be fast as
normally these routines are only used during probing before interrupts are
enabled.

Enabling interrupts in the driver would mean that the kernel can do other
things while waiting for the SCSI request to be processed by the drive, the
block located, read from the disc etc. Then ixfer() and iwait() will be only
called during the actual transfer from the drive. The big holdup in the kernel
is the polling waiting for the drive complete the seek (~10ms say) and actually
get the data). Optimising xfer() and iwait() would speed the transfers up but
would probably not help much in improving kernel responce unless IRQs are
active.

Does this make sense ?

>Also the routines mentioned by Mark as possibly needing recoding to speed
>things up must be called with interrupts disabled, so I don't see how
>they could be interrupted.
No the sfasixfer() and sfasiwait() may be interrupted. The interrupts work on a
priority scheme. Interrupts are masked out of the IOMD as required. This means
interrupts such as TIMER1 and TIMER2 have high priorities as will interrupt the
SCSI driver even if it was processing a SCSI interrupt. However one SCSI
interrupt would not interrupt another.

Cheers,
			Mark




-- 
Mark Brinicombe				amb@physig.ph.kcl.ac.uk
Research Associate			http://www.ph.kcl.ac.uk/~amb/
Department of Physics			tel: 0171 873 2894
King's College London			fax: 0171 873 2716