On Apr 11, 2006, at 6:30 PM, Sebastien Roy wrote:
Nicolas Droux wrote:
- If the "destination address" (as in mac_dest_update()) is used
only for IP tunnels, shouldn't it be part of the plugin data
for that MAC type?
It can't be transparent to Nemo because the address is passed up in
DL_NOTIFY_IND messages.
Isn't this address specific to the IP tunnels plug-in though?
No more so than unicast source addresses are specific to the
Ethernet plugin. There are (or will be) three different tunneling
plugins, and two of them use destination addresses. In the future,
I can see other types of MACs (including different kinds of
tunneling) that have this concept, so I don't think it's really
specific to IP tunnels.
If so, your statement would imply that the introduction of new
notifications types would require a modification of the framework
itself,
That's true, since all notifications are requested, generated, and
distributed by the framework.
even for notifications that are plug-in specific. Is this a
correct statement?
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 the mac_handle_t
would be passed through by the plugin, and the notification would
make it up to the MAC clients.
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.
- shouldn't there be a versioning mechanism between the plugins
and the drivers that depend on that plugin? I.e. the change of
an interface provided by one plugin shouldn't affect drivers
using different plug-ins.
I don't understand this comment. Drivers don't use plugin
interfaces at
all. Can you provide an example or be more specific?
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.
Thanks,
Nicolas.
--
Nicolas Droux, Solaris Kernel Networking
Sun Microsystems, Inc. http://blogs.sun.com/droux
_______________________________________________
networking-discuss mailing list
[email protected]
