On Thu, 2004-11-04 at 10:30 -0500, Alan Stern wrote: > It sounds more complicated than necessary, for system PM changes at least. > Isn't it true that whenever a system PM request is received that all the > user processes are in the refrigerator and hence no new block requests can > be generated? If so, wouldn't it be sufficient for IDE suspend simply to > wait until the request queue is empty? Nope. Two reasons why I prefer doing that (oh, and it's been there for a while and works) : - On PPC suspend-to-RAM, I don't freeze processes. I think this is unnecessary waste of time, and I consider the time needed to suspend to RAM as critical. I've had a perfectly working implementation of suspend to RAM doing that for a few years now. - I don't trust things like the new fancy IO schedulers not to schedule an IO behind my back (and I did see IOs sneaking in the queue after the suspend request btw). At least, freezing the queue makes the stuff solid. - The actual freezing of the queue is about 3 lines of code :) Sending a special request down the queue is the best even if you don't intend to block the queue, it synchronizes properly with pending requests, and gives you the opportunity to do what you have to do from a proper request context, that is within routines that will have "prepared" everything for you. For example, on IDE, the subdriver suspend/resume state machine funciton is called with the drive already selected etc..., you basically just need to send the taskfile you want, and get called back on completion irq, everything is handled for you like a normal request (irq timeouts etc...) Ben.
