Seb,
Sebastien Roy wrote:
- Since mac_register_t must always be freed by the driver immediately
after invoking mac_register(), could mac_register() itself free (i.e.
consume) the structure directly? Then you could get rid of mac_free().
I suppose it could. I don't have a strong feeling either way. I'm
trying to think if there would be a situation where a driver might want
to access the contents of the mac_register_t prior to freeing it (for
logging purposes maybe...).
OK, meem also had some other valid concerns about the failure cases. I
don't feel strongly about this particular point.
- Could m_ident be replaced by a proper version number passed as an
argument to mac_register()?
What would be the functional difference between having it be the first
member of mac_register_t and having it be a separate argument?
It is currently a version number in the form of a string. What did you
have in mind? Are you just commenting on the name of the field
(m_version instead of m_ident?), or on its type?
You already covered that case in a separate email.
- 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? If so,
your statement would imply that the introduction of new notifications
types would require a modification of the framework itself, even for
notifications that are plug-in specific. Is this a correct statement?
- 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?
- 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.
Nicolas.
--
Nicolas Droux, Solaris Kernel Networking
Sun Microsystems, Inc. http://blogs.sun.com/droux
_______________________________________________
networking-discuss mailing list
[email protected]
