Am Mittwoch, 31. Januar 2007 16:54 schrieb Alan Stern:
quoted text
> On Wed, 31 Jan 2007, Pavel Machek wrote:

quoted text
> > "cease IO"? No, I believe it is enough not to start new I/O. Userspace
> > is frozen at that point, it can't ask you to do I/O.
> 
> There may be I/O requests sitting in a queue, already submitted by
> userspace.  The suspend method should wait for existing I/O to complete
> and stop processing new entries from the queue.

As far as I understand it now, a frozen process will be in the refrigerator.
Thus it cannot be blocking somewhere else in kernel space. Yet we cannot
be sure there's no queued IO, as theres aio.


quoted text
> > > On resume():
> > > 
> > > 1. Don't worry about TASK_UNINTERRUPTIBLE
> > > 2. Do not restart IO that may call wake_up_interruptible()
> > > 
> > > When do we restart such IO?
> > 
> > We reuse signal handling code to do that for us. It is same situation
> > as when someone signals task doing I/O.
> 
> Again you misunderstood the question.  The driver must start queued I/O
> when its resume() method is called.  It should then be okay for the driver
> to call wake_up_interruptible(), even before tasks are unfrozen.

Isn't there some code in usbfs that'll do homegrown aio and deliver a
signal to a process if io is completed?

	Regards
		Oliver
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/