> I still feel that this merits its own case: the ioctl itself could, > in theory, be issued by any app.
How so? The DLD ioctl API will never be public. We may (on the other hand) commit the libdladm API. > 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's acceptable to me, but I'm just a PSARC licensee, so what I think doesn't really matter ;-) > > 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. Hmm, I think I'm thrown off by the name; "mac_register_priv_prop()" seems to be generic to all driver-private properties. > /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. Now I'm confused. I thought the goal was backward-compatibility with any existing non-canonical ndd parameters, but I don't quite see how that compatibility is provided given the "_" constraint above. Is there a mapping going on that isn't described in the original proposal? > > 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. That is one of the concerns, but I'm really trying to sleuth out the various edge cases. -- meem
