Hi David, > 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.
Technically, yes; architecturally no. Since we're basically at the same place as we would be when the reset() entry points are called, the same sort of assumption hold here also. I will add the following to the man page: "open(9E) and other entry points should not be called while the driver is in quiesce(9E)." > 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? Yes, as long as the driver can guarantee that no more asynchronous writes occur to system memory as operation to the open instances. I will add that to the man page as well. > 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. Fair enough. I will remove the data integrity clause. From Fast Reboot's perspective, it's preferred that the driver drop any scheduled or in-flight transactions. > 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? OK. How about "asynchronous writes to system memory" instead? > How will console output work during this process? Console output will continue to work until the chain of drivers for the console are quiesced, which will be performed last. > Also, which ddi services is the driver permitted to call and not > permitted to call as part of it's quiesce(9e) implementation? All DDI interfaces can be called except those prevented by devtree_freeze(). > 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.) We will probably require drivers to implement quiesce() in a lock-free, no-memory-allocation, do-the-bare-minimum manner to poke only the few registers to stop all asynchronous writes to system memory and interrupt generate. That's why the quisce() interface has an "arg" field... Thanks, Sherry -- Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
