Re: scheduler support to lock user processes out?

[David Young <dyoung%pobox.com@localhost>]

On Sat, Feb 16, 2008 at 03:15:56PM +0100, Matthias Drochner wrote:
> 
> dyoung%pobox.com@localhost said:
> > Suspension is not an all-or-nothing affair: it is both possible and
> > desirable to suspend individual device sub-trees. 
> 
> The S3 vs suspend-devices-to-save-power thing again...
> 
> > A driver is broken if it will touch the hardware it controls while that
> > hardware is suspended.
> 
> If one suspends a device due to power savings policy or on
> user request, this should be only done if the device is
> not in use. If the device is needed, it must be resumed.

My point was that a driver has a bug if it reads/writes registers from
a hardware device that has been powered down, regardless of how/why it
was suspended.

I don't think that fixed policies such as, "the system may cancel
user-requested suspension" or "users may not suspend drivers that are
in-use" belong in the kernel.

We already do suspend devices that are in-use.  We must suspend those
devices because, as you say,

> System sleep is different: User processes still have the
> device opened, they can even sleep within driver calls.

> If you'd want to allow to suspend a device while user processes
> are having it open you'd need to place hooks on every driver entry,
> and after every function call which might sleep, which would
> mean a lot of code in performance critical paths.
> (And even that would not be sufficient if the driver
> was MP capable.)

It is not as bad as all that.  I think that we have hooks in most of
the important places already.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933 ext 24