> 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.
