On Jun 2, 2006, at 6:51 PM, Sebastien Roy wrote:
On Thu, 2006-06-01 at 13:30 +0800, Cathy Zhou wrote:
Another issue comes up: I found that the MAC which claims the
MAC_CAPAB_POLL capability *must* have the MC_RESOURCES callback
function
to register its blank() function. This is not obvious and easy to
cause
problem. Can these two be associated somehow?
This is a very legitimate point, and one that I've thought about as
well. I'd like to hear from the Nemo I-Team about this, since this
could be something that is related to the splitting of the polling
capability into the separate blanking/resources and direct transmit
path
capabilities...
If someone from the Nemo team could confirm that we could, for
example,
safely move the negotiation of the mc_resources() callback out of the
list of callbacks provided at mac_register() time, and into the
MAC_CAPAB_POLL negotiation, then I'd be glad to do that (and amend the
PSARC fast-track accordingly).
This callback should be kept in the mac_callbacks_t for now. It is
currently used only when the polling capability is specified, but
this is only due to the current implementation of the polling
capability, which is going to be heavily revisited.
If a device advertises the polling capability but doesn't provide a
MC_RESOURCES entry point, the only impact is that no interrupt
blanking will be done for that device.
Nicolas.
-Seb
_______________________________________________
networking-discuss mailing list
[email protected]
--
Nicolas Droux, Solaris Kernel Networking
Sun Microsystems, Inc. http://blogs.sun.com/droux
_______________________________________________
networking-discuss mailing list
[email protected]
