cc-ing reply to network-discuss since that's where most of the Nemo
(GLDv3 - I wish it was never called that, it's too confusing) folks
hang out...

On 11/22/06, Garrett D'Amore <[EMAIL PROTECTED]> wrote:
GLD  could achieve this by having the original DLPI message (e.g.
DL_PROMISCON_REQ or DL_SET_PHYS_ADDR_REQ, or DL_GET_STATISTICS_REQ)
spawn a task (on a taskq) to call the entry point.  This task would also
be responsible for sending the reply message back upstream.


With v3 a.k.a. Nemo, the mac layer processing is divorced from STREAMS
by the data-link services module (dls). This is a functional
interface, which I did at one point code up with the possibility of
handling async. completion but it just got too messy, and none of the
existing drivers were using it, so I pulled it out.
Do you know of any current or forthcoming h/w that would require the
ability to asynchronously complete operations?

The benefit is that all GLD entry points (except of course,
gldm_send(9e)) (and possibly other GLDv3 entry points) would be free
from restrictions related to interrupt handling.

gldm_send() is not a v3 entry point. All v3 drivers are coded to the
'mac' interface - see usr/src/uts/common/sys/mac.h

 Paul

--
Paul Durrant
http://www.linkedin.com/in/pdurrant
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to