David Kahn wrote:
>> 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 framework should guarantee that the kernel is single
threaded at the point that quiesce is called, and that there will be no
subsequent IO performed to the device. I suspect that this guarantee is
already in place, but maybe the project team can clarify.
-- Garrett
> 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
>
>
