Cathy Zhou wrote: > Sebastien Roy wrote: >> 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.
Got it. If we make this a convention, then it might make sense to document it in the UV PSARC materials for future work to refer to. Also, for symmetry, since link creation operations also implicitly create link-ids, I'd expect that link deletion operations implicitly destroy the linkids passed in. I believe this is the case with the current libdladm functions. >> 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. I agree with that. Thanks for the clarifications. -Seb
