I am derailing this case on grounds of non-obviousness of its
architectural impact, and possible incompleteness. The discussion
already uncovered that there is more than a minor amendment to
PSARC/2004/253 "Advanced DDI Interrupt Functions" .
To prepare for the full review, the architecture should address the
impact on device drivers and on the subsystems they are part of.
If the scope of the project is intended to remain generic enough, the
material needs to reflect that more than one class of
device drivers were considered in the architecture.
To elaborate (see Garrett's previous email), the interrupt handles that
a NIC driver acquired are actually exposed to the MAC layer (see
PSARC/2006/357 - Crossbow), for enabling/disable the interrupts on demand.
The proposal should be clear on how the behavior of such drivers is
intended to be modified when ported to the IRM interfaces.
Should there be an extra notification event between MAC and the drivers
to invalidate the interrupt handles registered with MAC?
Are drivers supposed to insulate MAC from the real interrupt handles
instead, and, internally map to real handles that can be
added/removed? are they supposed to start "faking" the polling mode in
software on rx rings that lost their real interrupts for
example?
Cryptographic accelerators are another class of I/O where an external
framework (the Solaris crypto framework) relies
on driver notifications coming from job completion interrupts. See
PSARC/2001/557.
What such drivers are supposed to do for proper handling
DDI_CB_INTR_REMOVE ?
Should they block until the jobs drain and they get to call
crypto_provider_notification(READY), should they immediately
notify an error for all pending crypto requests?
Kais.
