Am Donnerstag, 1. März 2007 21:07 schrieb Alan Stern:
> On Thu, 1 Mar 2007, Oliver Neukum wrote:
> > 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.
>
> Oh dear! This means the entire kernel will have to be rewritten! :-)
>
> Seriously, exactly that assumption _is_ made throughout the kernel.
> That's why open() checks user privileges but read() and write() don't --
> they only check whether the fd is open for reading or for writing.
Down an interface and it stays down. Suspend an interface and it ...
Why?
> That difference is minimal. If there's ongoing I/O then setting the delay
> to 0 won't have any immediate effect. On the other hand doing an
> immediate suspend won't have much effect either, because the ongoing I/O
> will quickly cause an autoresume.
Very well, so autosuspend with delay 0 is 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.
>
> I can't think of any way to express the idea of "a specific purpose" in a
> form the kernel can understand. However the user could always disable
> autosuspend; that also should force an immediate resume and it wouldn't
Yes, only waking up, as opposed to wake up and keep woken up,
is useless from user space.
> have any races. (But it might lead to problems if the user then didn't
> have permission to re-enable autosuspend -- a perverse situation.)
Yes, that should be avoided.
> Well, we could do a privilege check in the attribute's store() method.
> But it would be a lot more flexible to have distinct attributes.
Yes.
> > > 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?
>
> Take a look at the definition of pm_message_t and tell me where you think
> the information could be stored.
How many in kernel data structures have been changed? Though if we limit
pm to autosuspend the point is moot.
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
