Jerry Gilliam wrote:
>
>>> 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?
>>
Yeah, I'd rather have that too.
>>
>>> 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".
>
So I have no concern with ddi_no_quiesce(), which is a reasonable
default behavior (the device doesn't require quiesce.) My concern was
with ddi_quiesce_not_supported(), which it sounds like even the project
team thinks nobody should use. (It sounded like this may have been
useful to the project team to identify the drivers they have looked at,
and make cscope easier to deal with, but that's still, IMO, an
implementation detail, and probably doesn't warrant promoting
ddi_quiesce_not_supported() into the public DDI. (Note that I'm
specifically not asking the team not to create the routine or use it,
I'm just saying lets not document or bless this as a valid approach. It
sounds like device drivers really need to take one of two paths:
1) declare that they don't require a quiesce by using ddi_no_quiesce()
2) implement a functional quiesce()
All other cases are just, if I understand properly, a short term
(hopefully!) bug.
- Garrett
>
> -jg
>
>
