On (03/06/08 17:39), Peter Memishian wrote: > > > > Seems fine to me. Regarding the `name' parameter to > > > mac_register_priv_prop(): I presume the caller will not provide the `_', > > > > Yes. the driver will be written to be consistent with dladm's > > private property expectations. the mac_ndd shim will add/delete > > the "_" to deal with ND_SET/ND_GET ioctls. > > I see. > > So will dladm be able to interact with these properties?
If we follow the solution above (prefixing the props with _), then yes. > Based on some of > the earlier emails in this thread, it seemed like you felt that was > unnecessary (and I tend to agree), but I don't see anything in the > spec > that prevents it. Maybe a MAC_NDD_PROP flag to > mac_register_priv_prop()? If we expect the driver to pass the "MAC_NDD_PROP" flag, then we only have advisory protection from exposing these via dladm. If we want mandatory protection, then we'd have to use some other method (such as the omitting the "_" solution for ndd props that I initially proposed). I think we should either choose to let dladm have access to these non-canonical props (which is useful because dladm brings persistence, and will let you look at default values) or enforce that it cannot access them.. having an optional flag creates one more confusing parameter, and a source of inconsistent behavior. --Sowmini
