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? > > > > 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. > 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. --Sowmini
