[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: scheduler support to lock user processes out?
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
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.
David Young OJC Technologies
dyoung%ojctech.com@localhost Urbana, IL * (217) 278-3933 ext 24
Main Index |
Thread Index |