> 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.
I'll look into it. > b. dls_devnet_prop_load_task() > > why softmac_hold_device() is needed? I guess it's not. Will remove. > 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())? Will file a CR. > d. Do we still need special handling for wifi devices in network-physical? We probably don't. Will remove. > Also, is it possible for "dladm init-linkprop" to take one specific name > (which requires the changes in the do_init_linkprop() function)? Yes, the code is already there. > 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. OK. -Artem _______________________________________________ networking-discuss mailing list [email protected]
