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

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

> For example, the _real_ suspend case (ie non-snapshotting case) has no 
> reason what-so-ever (apart from debuggability) to really stop any queues 
> etc. So if you want to do _real_ suspend, what you should do is exactly 
> what you propose: make it built up around the device model. Except you 
> don't actually need to empty or stop any queues, you just stop the devices 
> from handling them.

Not stopping queues but not servicing them instead ... hrm ... not that
much difference if you ask me :)

Especially with the network stack where if you really just stop
servicing, you'll trigger all sort of things in the higher levels that
you'd rather avoid (like transmit timeouts etc...), better tell it the
link is down and detach your queue to be left alone. (Or drop packets,
but in any case, it's easy, a matter of a call or 2 to tell the network
layer to not call your xmit anymore, and the network layer will do the
locking for you, so you don't need an addition spinlock to make sure
your xmit() was not just concurrently running with your suspend routine)

In fact, there is very little difference in practice as far as the
driver implementation is concerned. I don't care either way as long as
the driver is hardened against incoming things (requests, ioctl,
whatever) happening after it's been suspended...

In the case of block drivers, you really need to make sure that all
pending requests (tagged commands etc...) have completed and the easiest
way to do that in many cases (at least with IDE) is to have suspend
itself be a request in the queue that acts as a full barrier and causes
the driver to stop servicing the queue after the suspend request has
completed, a bit like if didnt't complete until resume in fact :) That's
how I did it and that fixed gazillion of problems back then.

In the case of fbdev, since you provice a memory mapped access to your
device memory to clients, you really need to tell them to stop mucking
around. We do that with the callback I added for fbcon, and for X, well,
that's what the console switch does (It's not perfect, as you rightfully
noticed, but it works fine will all sort of legacy crap including X
since forcing a switch to a console in KD_TEXT mode pretty much
guarantees the kernel gets back owership of the gfx hardware).

Then there are things we don't handle today and that we should handle:

Things like infiniband etc... who can map device memory in user space
will need additional mecanisms to sync with userspace to gets it's dirty
fingers off the hardware (unless you consider userspace freeze as an ok
solution). Same with sound.

Etc...

Ben.