non-hw drivers can't prevent fastreboot
A driver can prevent fastreboot in exactly one way: It "needs" to quiesce, yet fails to.
The specifics of "fails to" vary, either ddi_quiesce_not_supported(), not implemented, or returning failure.
However, it is all predicated on our belief that the driver "needs" to quiesce. If you are a pseudo driver, or a driver with no HW property, you are assumed to "not need to", and thus have absolutely of no way of saying that you can't.
You would think that making the system honour ddi_quiesce_not_supported() as actually meaning it, regardless of "need" was thus a good idea, but that too is flawed. pretty much every driver we have claims to not support it, many actually meaning they don't need it. Fixing ddi_quiesce_not_supported() would prevent any system from fast rebooting (this is not, necessarily, a bad thing). Someone would have to, in tandem, fix every driver that really meant they didn't need to quiesce to actually say that.
should_implement_quiesce() decides whether any quiesce you have will be listened to.
If you have a quiesce which is not ddi_quiesce_not_supported (irony!) it will be called (regardless)
but if should_implement_quiesce() did not return positively, even trying to quiesce and returning failure will not block the boot.
(I've run upon this by inspection trying to cause KVM to prevent fastboot, I have not yet tried it, and would love to be wrong).
Updated by Rich Lowe over 10 years ago
Presuming we had to fix this, Alasdair asked "What about the closed drivers?".
Presuming that we made ddi_quiesce_not_supported() actually work, and fixed up the open drivers to only use it if they meant it, we would likely have to rev DEVO_REV such that we could say "If DEVO_REV is not <the current one>, treat ddi_quiesce_not_supported() as before".