> [EMAIL PROTECTED] said: > > > > Recently discovered 6696737 caused us to reevaluate the already frowned > > upon attach(9E) time property access functions mac_prop_init/get. The > > conclusion was that we do not really need them, as long as the initial > > mc_setprop invocations occur before mc_start, which they do. This makes > > persistence "just work" for today's brusselized drivers and future > > drivers will follow suit. > > > > New webrev and cscoped workspace: > > > > http://cr.opensolaris.org/~artem/pers/ > > /net/aja.sfbay/export0/brussels/br-pers-dls/ > > > > Good news for the local optimizers among us is that the diffs are even > > simpler and 35% slimmer, with the same great flavor. > Artem,
I didn't look at the mdb related code, and below are my comments for other part of your code: a. Did you consider the DR case? See comment 2 above dls_devnet_rename(). Note that because a ddp->dd_vlanid could change (because of this case): - dls_devnet_prop_load_task() needs lock protection when accessing the dd_vlanid field. - in the case 2 of dls_devnet_rename(), you will need to unload the link properties associated with the old linkid and reapplies the link properties associated with the new linkid. b. dls_devnet_prop_load_task() why softmac_hold_device() is needed? c. Since link properties are all initialized by the new mechanism, do we still need the dladm_init_linkprop() calls in various RCM modules and libdladm function calls (for example, i_dladm_aggr_up())? d. Do we still need special handling for wifi devices in network-physical? Also, is it possible for "dladm init-linkprop" to take one specific name (which requires the changes in the do_init_linkprop() function)? e. I don't think we should to keep the link property values in the kernel and we can safely remove the whole dls_prop.c file, especially that 1) today there are no consumers for that, and 2) some of link properties simply do not go through the dls_set_prop() code path. If we need the kernel copy one day, it should be easy to add them back. Thanks - Cathy _______________________________________________ networking-discuss mailing list [email protected]
