Peter Memishian wrote:
> http://www.opensolaris.org/os/project/clearview/nemo-mactype-plugins.txt
> http://www.opensolaris.org/os/project/clearview/nemo-binary-compatibility.txt
Nice job! In the second document, this:
mc_callbacks is a flags field that drivers use to denote which _optional_
callbacks are set in the structure. The last two callbacks defined in
this structure are currently optional (mc_ioctl and mc_capab_get), and
thus the only two possible flags are:
... appears to be stale (mc_resources should also be named).
Good catch, I'll update that.
Also, regarding names: wouldn't mc_getcapab be more consistent with
mc_getstat and mc_setpromisc? (Likewise, mac_getcapab_t and MC_GETCAPAB
seem preferable.)
They would, I'll make these changes.
In addition, I presume that a plugin author should set m_plugin_data_size
should be set to zero if m_plugin_data is NULL? If so, I'd make that
explicit in the proposal.
Okay.
Regarding the DLPI notifications: it might be worth including a reference
to the PSARC case which introduced DL_NOTE_FASTPATH_FLUSH.
Yes, I'll do that.
Also, what's
our rationale for making DL_NOTE_PHYS_ADDR/DL_CURR_DEST_ADDR not be
Evolving like DL_NOTE_PHYS_ADDR/DL_CURR_PHYS_ADDR?
I admit to not having thought of those in the context of the greater
DLPI interfaces. I'm fine with creating these as Evolving.
Finally: why are the Section 4 interfaces not in the interface table?
Absent minded omission. I'll add those in.
Thanks,
-Seb
_______________________________________________
networking-discuss mailing list
[email protected]
