Nicolas Droux wrote:
I think so. I don't see a convenient way to generically inject
notifications into GLDv3 all the way from the mac module up to
individual DLPI STREAMS in dld.
Have you considered adding the plugin to the notification path itself
for plugin-specific notifications? In this case
I this case, the notification isn't plugin specific. More than one
MAC-Type plugin has the concept of destination address.
the mac_handle_t would
be passed through by the plugin, and the notification would make it up
to the MAC clients.
I don't understand how this can be made to work. How does the MAC
notification get translated to some DLPI notification? How do MAC
clients in the GLDv3 framework know what MAC notifications to register
for if such notifications are completely transparent to the framework?
My concern with the current proposal is that new plugin types might
require new entry points to be added to the MAC driver and client
interfaces of the common framework.
That's true, because there may be things that can be viewed as common
that are missing from the common framework. I don't see destination
addresses as plugin specific. They are no more plugin specific than
broadcast addresses or source addresses.
I'm talking about the format of the plugin data that is exchanged
between drivers and plugins. The format of that data is defined by
the plugin. What if a new version of the plugin requires a new format
for that data, shouldn't there be a versioning mechanism to track the
versions of individual plugins?
Ah, I see what you're saying. It seems like that's specific to a given
plugin's data format.
But in that case the plugin would have to be invoked to validate the
plugin data specified by MAC drivers when they register, for example to
detect a mismatching version number. I don't remember seeing such hook
in your proposal.
That's a good suggestion. I'll add a plugin operation to validate new
plugin data.
Thanks,
-Seb
_______________________________________________
networking-discuss mailing list
[email protected]
