>> >> 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?" :) >> > >So, rather than creating a new entry point for this, can't we instead >just make this a new question to add to the 20 questions? > >> 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. >> > >Hmm... that seems like a temporary problem to solve. I don't mind >having that as an implementation detail, but I question whether >ddi_not_supported() really needs to be part of the official DDI. I'd >rather not have it be a documented interface. >
The thought was that providing functions that drivers can reference for common default behaviors allows a number of ways to answer questions like "does this driver fail quiesce?" or "what drivers are preventing fast reboot?". With symbols, these questions can be easily answered via source, nm or kadb. There would be no way to enforce the use of these functions of course, but providing and using handlers for common defaults such as ddi_getinfo_1to1() and ddi_no_info() are convenient and obvious and seem like a practice we should encourage. Even if we don't quite promote these to the level of "official DDI". -jg
