On Tue, 3 Jul 2007, Matthew Garrett wrote: > On Tue, Jul 03, 2007 at 06:21:42PM -0400, Alan Stern wrote: > > On Tue, 3 Jul 2007, Matthew Garrett wrote: > > > We're used to the idea of applications blocking when a resource they're > > > using goes away - NFS has done it forever. > > > > You persist in evading my point. I'm not worried about applications; > > I'm worried about drivers. > > > > Let me put it explicitly: You're writing a driver. You're working on > > the read, write, or probe method. You add code to check if a system > > sleep is underway. Suppose the answer is Yes -- what does your driver > > do next? > > Leave the process blocked and defer any i/o until after resume. Why does > it need to be any more complicated than that? (1) The driver will undoubtedly hold some mutex or semaphore at the time it checks whether a system sleep is underway. You will have to drop it before blocking and then reacquire it afterward. (2) The driver may have been called by some other routine which holds a mutex needed for resuming the device. In this case the driver _can't_ drop the mutex and so the resume will deadlock. Okay, I agree that (1) can be handled without too much effort. But doing it adds an extra test to _every_ driver's I/O pathway. Freezing userspace does not incur all this additional overhead. (2) shouldn't arise during normal read and write operations, but it certainly _will_ arise during probe. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
