[brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008]

[sowmini.varadhan at sun.com]

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