On (03/05/08 22:10), Peter Memishian wrote:
>
> 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.)
There is a lager issue here: should user space apps that issue the
DLDIOC*PROP ioctls need mac.h to get the property numbers, or
should drivers include dld.h? As you point out, this debate was not
entered into for 2007/429, and the choice made there was that
DLDIOC*PROP ioctls would have DLD-prefixed property numbers,
all of which would be in dld.h. Changing that convention is not the
subject of this proposal, and would be better examined in its own
case.
For this particular case, since these flags are strictly between
the mac layer and the gld layer, we can rename them to MAC_PERM*.
> > 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?
It would be ignored.
--Sowmini
