Re: scheduler support to lock user processes out?

[David Laight <david%l8s.co.uk@localhost>]

On Thu, Feb 21, 2008 at 02:54:44PM +0000, Andrew Doran wrote:
> On Thu, Feb 21, 2008 at 06:27:41AM -0700, M. Warner Losh wrote:
> 
> > Correct.  FreeBSD's giant won't solve this problem, nor will NetBSD's
> > biglock when it covers less of the kernel.
> 
> We already have drivers that don't take kernel_lock and it's easy to switch
> it off. Even for the vast majority of drivers that run rith it, acquring
> kernel_lock doesn't have the intended effect.
> 
> The lesser hack of suspending user activity can be handled by adding another
> LWP state. We can't abuse the SUSPENDED or STOP states because they are used
> by applications. We can do something like:
> 
> - Offline all but the current CPU.
> 
> - Disable preemption. At this point there is only one user LWP left running
>   in the system, the LWP that requested the suspend.
> 
> - Transition all but non-critical LWPs to the new state PAUSED (or whatever
>   it's called). This would need to include a number of kernel threads, for
>   example those handling ktrace. It would need to skip others, like the
>   cross call threads.

When I was writing code to allow an embedded system to sleep (not netbsd)
I used what was basically a rw sleep lock [1] to control the drivers.
Before any hardware access the process-level code would acquire it for
read, and release after the block of work was done.
The sleep code would acquire it for write - effectively blocking all the
other accesses.
The sleep itself was done by a very high priority process.

        David
[1] you really need 'write-preference' as well.

-- 
David Laight: david%l8s.co.uk@localhost