Sowmini.Varadhan at Sun.COM wrote: >> 1182-1229: The checks for DL_ETHER make the code inherently not scalable. >> I think the only two cases are DL_WIFI, and not DL_WIFI. In other words, >> WiFi is the only special case, and every other media type is the norm. I >> believe you've started to codify this at line 311 by making the property >> applicable to DATALINK_ANY_MEDIATYPE, but stopped there. > > Correct. Actually one of the items in the Brussels roadmap is to > also provide support in DL_WIFI for mc_setprop/mc_getprop (this > came up in PSARC review- see ged-04 in > > http://opensolaris.org/os/community/arc/caselog/2007/429/20070912-2007-429-inception/ > > so the plan is to work on the wifi drivers, as part of driver > conversion, at which point the DL_WIFI specific code will be merged > in as a public property.
Okay, so will you fix the code to not check for DL_ETHER specifically? >> 1189,1209,1268: The caller of these functions already knew the media type >> so that it could compare it against pd_dmedia. It's inefficient to go the >> door call a second time to get the same information that we already had a >> moment ago. A better approach might be to simply pass in the media type as >> an argument to these functions. > > But the caller in this case has media type DATALINK_ANY_MEDIATYPE. The callers are i_dladm_set_single_prop() and dladm_get_linkprop(), both of which have the actual media type of the link. > so we can't avoid doing another call to ladm_datalink_id2info > (unless we change the semantics of pd_set). Yes, I'm suggesting that you pass the media type into pd_set() and pd_get(). Doing two identical door calls in succession to get values from a daemon makes no sense to me when we already have the needed values and can simply pass them in as function parameters. -Seb
