Re: [PATCH 2/2] Fix console handling during suspend/resume

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Tue, 2006-06-20 at 19:40 -0700, Linus Torvalds wrote:
> 
> On Wed, 21 Jun 2006, Benjamin Herrenschmidt wrote:
> > 
> > But the driver queue isn't quiescent !
> 
> AND WHAT THE HELL DOES THAT HAVE TO DO WITH THE DRIVER?
> 
> It's not up to the driver to worry about request queues. If you guys think 
> it is, you have your heads so solidly up your nether regions that it's not 
> even funny.

It's the driver that gets the suspend() request from the bus layer
(device model if you prefer, but in bus order) and thus is responsible
for stopping it's own request queue. In some drivers, requests queues
are even completely handled locally by the drivers themselves.
 
> Dammit, stop trying to make that a driver issue. It isn't. Drivers should 
> not have to worry about things like that, because it's not actually the 
> driver that even _does_ any of the request queue stuff. 

In some cases it is.

> That's _all_ at a much higher level, and trying to push it down to a driver writer is not 
> just stupid, it's so incredibly broken and idiotic that it's not even 
> funny.

Yeah yeah yeah ... so give concrete examples of how things should
happen.

> If you want to take a snapshot of memory, you do NOT ask the drivers to 
> just make everything quiet. You start from the upper layers, make things 
> quiet there, and _than_ you ask the driver to also shut up.

Or you ask the drivers who ask their providers to shut up etc... all the
way up the chain. Works like a charm _and_ allows you to have proper bus
ordering. Going downard the chain does NOT.

> But the fact is, IDE drivers don't even have to be told to shut up. If 
> there are no requests coming in from above, then they will be quiet on 
> their own. So, pretty much by definition, a freeze/unfreeze event for an 
> IDE driver had better be pretty much a no-op, or you have serious serious 
> problems anyway.

And how do you make sure there is no request coming from the above when
a given segment of a bus is going offline or being power managed or
whatever and thus a given driver needs to make sure it's not fed any
requests ? stop the entire system block layer ? What if it's not a block
driver ? Iterate through all subsystems in the kernel ? What about
drivers that implement their own internal request queuing mecanisms
(that aren't block drivers for example) ? What about ioctl's or such
things coming from userland ?

> Trying to claim anything else is beyond stupid.

Yeah  yeah, big words, insults, whatever you want, I still see all sort
of practical examples where my approach currently works and no way yours
will ... 

> And yes, I realize that the suspend/resume code has done some damn stupid 
> things. That's not an excuse for then making things _worse_ by not even 
> admitting that they are idiotic and bad.

facts, please. How long since you have put your hands in a driver btw ?

Ben.