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.
- 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.
- it seems that GLDv3 could implicitly load plugin modules on demand
according to the plugin type specified by the driver instead of
relying on the drivers to be compiled with an explicit dependency.
This would avoid locking us in with these plugin module names since
they'll need to be part of the public MAC interface.
This is something that I investigated when writing the design document.
If there's an easy way to do this, then I'd be up for implementing it.
What would be the method?
How about something like this: a new module type could be introduced
(e.g. "mac/{ether, ib, ...}"). At MAC driver registration time, the name
of the plugin is passed by the driver (e.g. through the m_type_ident
field of mac_register_t). The MAC layer can modload() the plugin module
at that time, and holds it until the MAC unregisters.
This sounds feasible, and I like the idea of having these be dynamically
loaded. Unless there aren't issues with this approach that others can
think of, I'll modify the document to reflect that.
-Seb
_______________________________________________
networking-discuss mailing list
[email protected]
