On (03/06/08 14:25), Peter Memishian wrote:
> > 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 ;-)
Would PSARC like to see this coalesced into this case? One of the
points raised by Garrett, when I initially combined PSARC 2008/171 and
2008/175 into one case, is that it's better to keep them separate
so that the mail threads discussing the issues can be kept sepaarte.
> > 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.
I initially called it "mac_register_ndd_prop", but Garrett suggested
the latter name. I'm not particularly attached to one or the other.
>
> > /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 non-canonical ndd props are usually variants like
"adv_asym_pause_cap" instead of "adv_asympause_cap" etc. In this
particular case (adv_asympause_cap) Brussels provides the cleaner
implementation of the flowctrl property.
Thus the non-canonical-ndd-param support is only in place for user
apps and scripts that have commands (or equivalent c code) that
does "ndd {-set, -get} /dev/<drv> adv_asym_pause_cap <..>".
We *could* enforce the private prop implementation of these in drivers
to prefix the name ("adv_asym_pause_cap") with a "_" ("_adv_asym_pause_cap")
and add the "_" prefix when translating the ndd call into a private
prop call in GLDv3, but, while this allows the property to be
accessed via dladm, it creates more confusion in the driver
implementation (use "ndd -set .. adv_asym_pause_cap", or
"dladm set-linkprop -p _adv_asym_pause_cap"). It's not even clear
to me that we need to support many of these non-canonical props
via dladm (there's no "backward" compat issue here, unlike ndd).
FWIW, I spelled out the alternatives are laid out in
http://mail.opensolaris.org/pipermail/brussels-dev/2008-February/000709.html
1.1 make the driver implement the non-canonical property as
"_link_tx_pause" and have mac_ndd.c prefix the "_" when calling
the driver
1.2 go with my prototype, which would make the non-canonical props
inaccessible from dladm. Note that /sbin/dladm filters out
properties that don't start with "_"
I see no clear advantage in either of these 2 choices. Morever, as
we convert each driver, we are cleaning up most of the non-canonical
props, so I made the simpler choice of 1.2.
Note that, esp after PSARC 2008/175, the dladm private prop mech
has an edge over ndd because of the persistent settings provided and
access to default values
> > > 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.
Ok.
--Sowmini
