Sebastien Roy wrote: > Folks, > > There is currently (in the Clearview gate) little uniformity in libdladm > functions. Some take link names (like the aggregation management > functions), others take link id's (like some of the VLAN management > functions, and the create function even takes both). > Currently, I basically use the rule that linkname is only used in dladm_xxx_create() functions (as linkid isn't known yet), and other functions all take linkids.
If there are any exceptions, please let me know. > I believe we need consistency, and it's not clear to me which model is > better. If we require callers of the API to translate names to ID's, > then application code may be more complex. On the other hand, if > applications use link-id's, they can use a single link-id for the > lifetime of the process and not have to worry about being subject to > link renames. Another variable is that we don't view renames as a > frequent or normal operation... > I feel that taking linkid should be the way to go, even it is may be more complicated. The reasons for that is: a. like you said, the API users won't need to worry about the link name changes. b. It is easy to find problems that it makes sure every libdladm users needs evaluate the impact of a rename operation. For example, when I merge the UV gate with Nevada today, it won't remind me that there is interaction between an rename operation and the NWAM application. c. Some applications, if it doesn't care about a link name change at all, it might simply save the linkid instead of linknames in its structures or even configurations. Thanks - Cathy
