>NAME > quiesce - quiesce a device > > The quiesce() function will be called once for each instance of > the device for which there has been a successful attach(). The > system guarantees that the function will only be called for a > particular dev_info node after a successful attach(9E) of that > device. The system is not single-threaded when quiesce() is > called, so the driver must ensure that concurrent accesses to the > device when quiesce() is invoked is correctly coordinated. The > driver can choose to drop outstanding I/O instead of waiting for > them to complete as long as it can guarantee on disk data > integrity. The driver must cancel any outstanding timeouts and > remove outstanding tasks from taskqs before returning successfully > from quiesce().
I think the definition for quiesce(9e) needs some more work. What I'm reading above is fairly vague. Specifically, can open(9e) or any other entry point be called while the driver is in quiesce(9e)? I would think we would want to guard against that, and if not, the driver needs to know that. If the intent is that nothing else will be called while the driver is in quiesce(9e), please state that guarantee in the man page. Second, are there open instances of the driver when quiesce(9e) is called, or does the framework guarantee to close all open instances of the device first? Also, the phrase "guarantee on disk data integrety" is not well-defined from a driver perspective. If I put my driver hat on, I really have no idea what that requirement is. Do you expect the driver writer to do something specific in that case, or just reset the controller, dropping any scheduled or in-flight transactions? How does it know if the disk data integrety requirement can be met. Finally, I'm not sure if you want to say anything about DMA mappings, etc. I guess they can be thrown away because the driver for any iommu in the path (yes, x86 has them too) will end up being reset by its driver? How will console output work during this process? Also, which ddi services is the driver permitted to call and not permitted to call as part of it's quiesce(9e) implementation? I guess what you are doing is loading the new ramdisk or kernel into memory and then calling quiesce(9e)? How would that work in a panic situation? (Yes, I saw that's part of phase 2, but it still needs to fit these interfaces.) -David
