Am Montag, 26. Februar 2007 03:37 schrieb Alan Stern:
> On Mon, 26 Feb 2007, Oliver Neukum wrote:
> Next you'll be saying that people will want to specify the delay more
> precisely than the nearest second...
Am I that predictable? It occured to me, but the process takes so long
that it makes little sense.
> > > imagine a situation where you would really want to do that.
> > >
> > > In addition it gives us a useful way to represent no autosuspend (although
> > > I suppose we could use negative delay values for that purpose).
> >
> > We shouldn't. The clean way to do this is to have a boolean setting.
>
> Not so. The collection of possible settings is
>
> {autosuspend immediately, autosuspend after 1 second,
> autosuspend after 2 seconds, ..., autosuspend never}.
Why? What reason is there for destroying the delay although you just
want to switch of autosuspension for now?
Consider this. Doing suspend at all or not can be critical to
functionality. According to the spec it shouldn't be, but it is. Whereas
we have established that a driver should be ready to deal with
suspension at any point in time. The delay is not a security question,
the flag is a potential DoS.
> > To elaborate a bit. You wanted to introduce a capability to suspend
> > a device immediately, but without regard to its willingness to autosuspend.
> > However the device was to always wake up on demand. It seems to me that
> > this is indistinguishable from an autosuspend with zero delay.
>
> It isn't indistinguishable. There is a very real difference: The
> capability I wanted to introduce would operate only when userspace makes a
> specific request. Autosuspend with zero delay would operate autonomously
> with no user intervention, once the delay is set.
>
> Or did I misunderstand your point? Waking up on demand is distinguishable
> from autosuspend with zero delay because autosuspend is merely an
> optimization (improved power usage), whereas waking up is necessary for
> proper functioning.
If we take the delay value as such, that is only to specify a delay, which
I find logical, if it is not mixed with the master on/off switch, a delay
of 0 should mean "attempt to suspend now"
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.
I cannot see the difference to a "suspend now" trigger, if we resume on
demand. Resumption on demand does mean that the final decision is in
the driver. The device can stay suspended only if the driver agrees.
I see no difference to autosuspend in that regard.
Sure autosuspend is continous, but apart from that?
In addition, if we do it that way, we don't add a third code path for the
immediate trigger.
Regards
Oliver
-------------------------------------------------------------------------
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
