A few minor comment on some details:
> Interface Classification Comments
> -----------------------------------------------------------------------------
> mac_register_priv_prop Committed Section 4.1
> DLD_PERM_{READ, WRITE} Committed r/w permissions
> for ndd properties
> defined in <sys/dld.h>
I'm surprised to see the DLD namespace (and the <sys/dld.h> header)
leaking into the MAC driver API. The DLD prefix is intended to be used by
the private API between libdladm and the data link driver (dld) itself.
It's not clear to me what that has to do the MAC driver API exported to
drivers. (I see that the existing Brussels link properties use "DLD" too,
but I don't understand that either. I also see there appear to be unused
DLD_NDD_{READ,WRITE} #defines adrift in Nevada.)
> Synopsis:
> void mac_register_priv_prop(mac_handle_t mh, char *name, int flags)
Seems like `name' should be `const char *' and `flags' should be unsigned.
> Description:
>
> Drivers wishing to support non-canonical ndd parameters must provide
> the names of these parameters to the GLDv3 framework after
> succesfully completing mac_register() in their attach(9E) routine.
>
>
> Parameters:
> mh mac_handle_t obtained after succesfully completing mac_register.
> name property name of the non-canonical ndd prop to be registered
What happens if the name passed in is already a canonical ndd property?
Is it just silently ignored?
> flags property flags defined in <sys/dld.h> which may be a logical OR of
> {DLD_PERM_READ, DLD_PERM_WRITE}, describing read/write permissions
> for the property.}
--
meem
