Re: [PATCH 4/4] USB: export autosuspend delay in sysfs

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
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel