Peter Memishian wrote:
> > 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?
>
> I don't see an issue with user-space making use of <sys/mac.h> -- it'll
> ultimately be a public part of the GLDv3 API. On the other hand, having
> e.g. third-party GLDv3 drivers pulling in an implementation detail like
> <sys/dld.h> is a problem. (Note that user-space apps are otherwise
> insulated from the DLD namespace since e.g. DLDIOC*PROP is actually issued
> by libdladm on behalf of userland.)
>
I tend to agree. If its desirable for consistency, one can do something
later like:
#define DLD_PROP_PERM_READ MAC_PROP_PERM_READ
This allows for keeping the names at least a little more consistent in
consuming code.
> > > What happens if the name passed in is already a canonical ndd
> > > property? Is it just silently ignored?
> >
> > It would be ignored.
>
> I presume the same would be true if it attempted to register a framework
> link property name like "autopush"? If so, that seems dangerous since
> namespace collisions that may be introduced over time (e.g., as we grow
> the set of framework-native link properties) will go unreported, which may
> lead to unpredictable behavior.
>
This is a general risk with private properties. We should be pressing
*really* hard for the complete eradication of unqualified private
property names, and frankly also pressing pretty hard for drivers to
avoid use of "synonyms" and such, but instead use official public
properties where possible.
But, along these lines, I did have the thought (which won't really help
for ndd) that dladm could have a different flag/option to access private
properties. Sort of like cfgadm's -x option for "hardware-specific"
operations, and -c for standard operations. This also would help
underscore to the user/admin that the property names are not necessarily
portable across drivers, and it would avoid the namespace collision
problem (at least at the dladm level.)
-- Garrett
