Seb, A few more comments on your latest drafts:
* http://www.opensolaris.org/os/project/clearview/nemo-binary- compatibility.txt
- 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().
- Could m_ident be replaced by a proper version number passed as an argument to mac_register()? I'm uneasy about still relying on the SCCS version number of a header file for versioning. It should be possible to make changes to mac.h that don't necessarily change the blessed public interface. There's also a risk of mismatching m_ident between the ONNV or ON10 of mac.h for the same MAC driver interface version.
- 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?
* http://www.opensolaris.org/os/project/clearview/nemo-mactype- plugins.txt
- same comment on the need for a free routine, mac_type_free() in this case.
- shouldn't there be a version number for the interface between the plugins and GLDv3?
- 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.
- 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.
-- Nicolas Droux, Solaris Kernel Networking Sun Microsystems, Inc. http://blogs.sun.com/droux _______________________________________________ networking-discuss mailing list [email protected]
