Am Mittwoch, 31. Januar 2007 16:54 schrieb Alan Stern: > On Wed, 31 Jan 2007, Pavel Machek wrote: > > "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. > > > 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
