> > 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. > > As this points out, we're on a slippery slope -- once applications are > regularly interacting with linkids through APIs, it seems like only a > matter of time before they're exposing them into the administrative model > (and (c) almost does that).
What administrative model you mean here. Whenever these applications (which is libdladm API users) need to export this link to the administrative modle, they should call the dladm_linkid2info() to get the link name, and only show link names. Thanks - Cathy > This was something I wanted to avoid -- but > maybe it can't be avoided. >
