On Mon, 2006-04-10 at 23:39 -0700, Nicolas Droux wrote: > 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().
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...). > > - 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? > 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. I completely agree, and I'll fix that SCCS dependency. > There's also a risk of mismatching m_ident > between the ONNV or ON10 of mac.h for the same MAC driver interface > version. Right. > > - 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. > > * 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. Not sure about this. > > - shouldn't there be a version number for the interface between the > plugins and GLDv3? Yes, good point, I can add one. > > - 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? > > - 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? -Seb _______________________________________________ networking-discuss mailing list [email protected]
