On Mon, 26 Feb 2007, Oliver Neukum wrote:
> If you want to specify it in milliseconds, I have no objections. Other times
> are also given in those units.
Seconds are easier, except in this one case where you want a value less
than 1 second. I'm inclined not to worry about it and keep things
simple.
> > If you have told the kernel you want the device not to autosuspend, there
> > is no reason for the kernel to remember an autosuspend delay. If you then
> > want to tell the kernel it's okay for the device to autosuspend again, you
> > can go ahead and re-specify the delay you want to use. The kernel
> > shouldn't bother to remember the old delay.
>
> a) The kernel will (or rather should) export its oppinion whether a device
> should be suspended (eg. from the blacklist or set by a driver)
Be careful in your choice of words. Do you mean "suspended" or
"autosuspended"? The kernel basically has no choice about whether a
device should be allowed to suspend. It _must_ be allowed; otherwise
swsusp won't work.
The kernel's opinion about whether a device should be autosuspended _is_
exported through the power/autosuspend attribute. Values > 0 mean yes (or
>= 0 after I change it), other values mean no.
> b) The security implications are different
In what way? Why are you so concerned about security implications?
Almost all of the writable files in sysfs are writable only by the
superuser; this doesn't have to be any different.
> > I don't understand your point. Preventing a device from autosuspending
> > isn't a denial-of-service, although it might be a denial-of-power-savings.
>
> _Allowing_ it is, as we have buggy devices which crash.
Yes. That's what PAM is for, right?
> > > Thus a sequence of
> > > a) read old delay
> > > b) request 0 delay
> > > c) restore old delay
> > >
> > > should suspend the device if it is not doing IO.
> >
> > Yes, except that both you and Greg have requested that step c) should
> > wake up the device and restart the timer using the reinstated old delay.
> > Of course, if you stop after step b) the effect will be to suspend the
> > device as soon as it is no longer in use.
>
> I am complicated. I have conditional wishes.
> I want step (c) to wake up the device only if on/off is included in that
> value.
> I can't speak for Greg, though.
Now you're asking to have two values included in a single sysfs write
(on/off and delay). That's a no-no. :-)
> > By now I'm no longer sure what you're asking for. :-)
>
> - separate on/off switch
What good is a separate switch? What's wrong with combining it along with
the delay?
> - allow 0 delay
Okay.
> - don't do an immediate suspend independent of autosuspend
Why not? In extreme cases the user can force an immediate suspend by
doing suspend-to-RAM anyway. This merely preserves the capability we are
about to lose when the power/state attribute disappears completely.
> > Add a new power/suspended attribute. Writing 1 will always try to suspend
> > immediately (_not_ an autosuspend!) and writing 0 will always resume
> > immediately (but will start the autosuspend timer).
>
> This is problematic, as it is a totally new code path.
No it isn't. It's the code path used for traditional
suspend-to-{RAM,disk} and also used by power/state.
> > BTW, note that an autosuspend request is different from a plain old
> > suspend request. Autosuspend will fail if an interface requires
> > remote-wakeup capability but remote wakeup is disabled, whereas a regular
> > suspend won't fail.
>
> Yes, that too. It makes that even more asymmetric. We wake up on demand
> in only one direction.
I don't know what you mean. We _always_ wake up on demand. What's
asymmetrical about that?
> If you want such an interface I'd suggest that it mean
> that a device stay suspended until the user says so.
No. One more time:
WE ALWAYS WAKE UP ON DEMAND!
If the user really wants a device to suspend and not wake up, he can take
more drastic action. Just don't send it any more demands. Unbind it from
its driver. Unplug it -- and that would save even more power!
Alan Stern
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
