Am Mittwoch, 28. Februar 2007 19:44 schrieb Alan Stern:
> As David mentioned, there are also other reasons for getting rid of
> power/state.
Then I suggest that we go through to make sure we don't repeat them.
> We never came to a solution partly because people have all sorts of
> varying requirements. With USB at least the problem is relatively simple:
> Devices are either on or suspended. Hopefully we can figure out a useful
> API.
It is not so simple. We are not making a simple interface to control a
device's power state. The power state can change due to other factors,
autosuspend, remote wakeup and demand for IO. Complicated by dealing
with devices and interfaces.
> I/O requests arise from two sources: the device itself (remote wakeup) or
> userspace. I agree, we need to give people the ability to suspend devices
> with remote wakeup disabled. But it doesn't make sense to say that we
Yes.
> shouldn't autoresume when an I/O request arrives from userspace -- in
> effect, such I/O _is_ a request from the user to turn the device back on.
There is no uniform user space. IO requests originate from different users
and sometimes the kernel itself. You cannot assume that the priviledge to do
IO with a device at the time open() (or equivalent) was called means that
this priviledge remains.
> Let's try to step back and see the big picture. And while you think about
> this, consider it not just from the point of view of the kernel or the
> user -- think about what would be most useful to some sort of power
> management daemon.
>
> Clearly we want the user to be able to specify an overall autosuspend
> delay. (You have even asked to have separate delays for individual
> interfaces.)
Yes.
> Setting the delay to 0 is almost equivalent to asking for an immediate
> suspend. The difference arises only when an interface driver requires
or there's ongoing IO.
> remote-wakeup capability and the user has disabled it (or the device
> doesn't support it). There also has to be a convenient way for the user
> to force a suspended device to wake up; setting the delay to something
> larger than 0 would be good enough.
I am afraid not. This introduces a race condition. If a device is woken up
for a specific purpose, the better interface would be an interface that
made the device stay awake until that purpose is satisfied, however long
that may take.
> We need a way to prevent & allow autosuspend for a device. Prevention can
> be accomplished in a less-than-elegant way by setting the delay to a
> negative value, although perhaps we could parse the word "never" or "off".
> The permissions requirements, both for this and for the delay, aren't
> entirely clear. (Most sysfs attributes are writable only by root,
> anyway.) If the two operations require different permissions, then
> they probably shouldn't be controlled by the same sysfs attribute.
Yes, otherwise the kernel imposes that this priviledge cannot be split.
> Open question: Do we need a suspend mode in which the device _doesn't_
> wake up on request? I don't think so... and in any case, there's no way
> to pass this information (whether to ignore I/O requests) to the driver.
Why not?
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
