On Wed, 4 Jul 2007, Paul Mackerras wrote:
> Whether or not to resume a suspended device when an I/O request comes
> in is a policy decision, and there could be cases where the user wants
> I/O requests to be blocked, or to fail, or to be dropped while the
> device is suspended, even for runtime power management. For example,
> a sound card could be suspended due to a low-battery condition, and in
> that case you would want the driver to just drop any data that
> userspace tries to write to the soundcard.
We have provisions for that (my earlier description was somewhat
incomplete).
> > Yes, the code could be changed to keep track of the reason for a device
> > suspend. But that just raises the old problem of what to do when
> > there's an I/O request for a suspended device during STR.
>
> Is this actually a real problem? I would think the policy would be
> "block" for block devices (pun not intended :), "drop" for network
> devices, etc.
It is indeed a real problem, or at least, it can be.
> > Consider a particularly troublesome case: During STR, a non-frozen task
> > writes to /sys/bus/BBB/drivers/DDD/bind. The sysfs core grabs the
> > device semaphore and calls the driver's probe routine. If the driver
> > isn't PM-aware it simply tries to initialize the device and fails
> > because the device is already suspended. That's no good; it isn't
> > transparent.
>
> How did the device get suspended if it didn't have a driver? If it
> did have a driver, why didn't the bind attempt fail?
Bus subsystems can suspend devices with no drivers.
> Suppose the device-model core code simply blocked all bind and unbind
> requests while suspend is under way, until resume is finished.
> Wouldn't that solve the problem?
It would help. It would help even more if the sysfs core also blocked
all I/O while suspend is under way. (Although this might be tricky,
considering that the suspend is initiated by a sysfs write...)
The fact remains that lots of drivers would still need to be changed.
In the read and write methods someone would have to add code amounting
to this:
if (suspend_is_under_way()) {
mutex_unlock(...);
block_until_resume();
goto restart;
}
Freezing userspace is a small amount of code by comparison.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
