Sherry Moore writes: > 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,
... we hunt them down and eject them from the source base. > it is clear that > devo_quiesce is a dev_op that needs to be implemented, or set to Oh. That sentence didn't end the way I was expecting it to. ;-} > 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. That doesn't work, for exactly the reason you stated above: you've got to support NULL so that you can support old drivers, and that means NULL should work on new ones as well. In fact, for drivers that are written to support multiple releases of Solaris (e.g., those in the CS consolidation or in external open source repositories), the most likely case is that they'd leave that structure member uninitialized on purpose rather than deal with a new DDI function that might not be present. Finding the non-quiesce-compliant drivers is just going to be harder than find|xargs grep. I don't think expanding dev_ops works well here. As David Kahn mentioned, this is just another form of detach(9E). -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
