Hi Garrett, > So one thing that is slightly confusing to me is, why do we need both > ddi_no_quiesce(), and ddi_quiesce_not_supported()? And how is the entry > point being NULL interpreted? > > It *seems* (and maybe I'm being naive here), that > ddi_quiesce_not_supported() may not have much value -- drivers that have a > bug where quiesce is necessary but lack the current can just implement a > trivial "return DDI_FAILURE" quiesce in the meantime -- not much more > effort than stubbing in the ddi_quiesce_not_supported(). Additionally, > unlike the ddi_no_quiesce() case, the driver is going to need to be > modified at some point anyway, right?
NULL entry point will be treated the same as ddi_quiesce_not_supported() (or whatever function name we eventually settle on). These functions are introduced so that when new driver developers start writing drivers by making copies of existing ones, it is clear that devo_quiesce is a dev_op that needs to be implemented, or set to ddi_no_quiesce() or ddi_quiesce_not_supported. If it is set to ddi_quiesce_not_supported, I would like to see someone on the ARC committee asking, "Uh, why is quiesce not supported?" :) In addition, we have a clear picture on the number of drivers that don't require quiesce, and those that do but haven't implemented it yet. In other words, one can simply look for ddi_no_quiesce and ddi_quiesce_not_supported in cscope instead of dev_ops and manually sort through them. > Finally, it may be informative/helpful to list some example drivers in the > case materials that need to have quiesce implemented, as well as perhaps a > couple that don't. Will do. I have write that up and have Jerry copy to the materials directory. Thanks, Sherry
