On Oct 28,  4:06pm, Ale Terlevich wrote:
> Subject: Re: State of Powertec support ?
>
>
> On Mon, 28 Oct 1996, Simon Proven wrote:
>
> >
> > >  Why then are the SCSI drivers so slow?
> >
> > suffer because polling is fast under RISC OS, because you're always the
> > foreground task when doing disc transfers.  Unix does it differently.
> >
>
>   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.
>
>   Is this wrong?

This is sort of right. The way NetBSD works is that the kernel is split into
two layers. One is the interrupt layer and data in that layer is global and
common to all processes. The other layer is between the interrupt layer and
user space and everything at this layer is split into process contexts. A
context switch occurs when the interrupt layer (not quite true, but it will do)
changes the currently running process. When the process is running in the
kernel (SVC mode, etc) context switching is disabled. Interrupts are still
running, however (NetBSD uses *lots* of interrupts to do system housekeeping).
This means you can do things like switching virtual console even after
something has wedged in the kernel (or during a polling driver tape drive
access for instance). I also suspect that the polling drivers are running with
*all* interrupts enabled at least during the polling loop. This effectively
bumps them down to lowest priority.

> 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.
>
>   Confused yet again...

I don't think they do have to be called with interrupts disabled. The
interrupts are given priorities and during processing a disk interrupt for
instance it would be quite normal to have anything higher priority still
enabled (I believe the hardware clock is higher priority but I could be wrong).

Cheers

Rob

--