Re: requirements for suspend()

Am Mittwoch, 9. Mai 2007 00:06 schrieb Alan Stern:
> On Tue, 8 May 2007, Oliver Neukum wrote:
 
> > Who would send a signal? If this is called with pending URBs, aren't
> > tasks frozen?
> 
> disconnect() can be called as a result of a user doing:
> 
> 	echo -n $device_name >/sys/bus/usb/drivers/$driver_name/unbind

But disconnect kills the URBs outright without waiting.

> and a signal could occur if the user presses ^C.  suspend() can also be 
> called as a result of writing to sysfs.  pre_reset() can be called as 
> part of a reset initiated through usbfs.  None of these things require 
> tasks to be frozen.

That is correct. But a signal could happen for a lot of other reasons, too.
Basically, doing so would mean:

1. signals have different semantics depending on when they arrive
2. signals can mean data loss

I don't think we can do that. If you hit ^C in that example, the
suspension should be canceled, but not completed extraordinarily.
But cancelling a suspension is not so easy either.

	Regards
		Oliver


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel