Sowmini.Varadhan at Sun.COM wrote:
> On (03/06/08 13:36), 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 still feel that this merits its own case: the ioctl itself could,
> in theory, be issued by any app. Moreover, the naming convention here
> is not clear to me: will DLD*PROP ioctls pass down a dld_ioc_prop_t
> structure that has pr_num that starts with "MAC"? In this model,
> will dld_ioc_prop_t structures live in dld.h, and the MAC* definitions
> in mac.h? There's a lot of parameters here, and I am not comfortable
> mixing those parameters into this case. We could address the
> naming conventions for the DLD*prop in a separate case. Is that
> acceptable?
>
It is to me. Meem?
>
>> > > 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
>>
>
> This is not intended to be a general purpose mechanism for property
> management at all, and is really only intended for the "legacy" ndd
> props. /sbin/dladm itself will filter out private properties that
> do not begin with "_". In the example that you cite, if "autopush" is
> registered, then the (driver-private) implementation would never be
> accessible via dladm becuase (1) it does not start with "_" (2) the
> defined precedence is for the public property.
>
Thanks for the clarification regarding the "_" prefix.
>
>> the set of framework-native link properties) will go unreported, which may
>> lead to unpredictable behavior.
>>
>
> If the concern is around the lack of error reporting, the synopsis
> of mac_register_priv_prop can be changed to return an int, with 0
> return status indicating success, and EEXIST indicating that the
> registered name is a duplicate.
>
Probably not of much value, IMO. (We need to be trying to wean
developers off of private properties and ndd, and if I can avoid having
to have error checks in the driver, it will make for
shorter/cleaner/simpler code in the driver -- that's a good thing IMO.)
I'd like to ensure that the "names" passed to mac_register_priv_prop
also start with an underscore.
-- Garrett
