A common complaint seems to be cropping up regarding the dladm rename-link subcommand, which is that it is overloaded to execute two different operations. Consider the command "dladm rename-link A B", where A and B are link names adhering to the usual link naming constraints. It could mean the following depending on context:
1. Give link A a new name of B. All of the link properties associated with link A are still associated with this link with a new name of B. 2. Associate link A's physical device with link B, and destroy link A and all of its properties. This is done if link B's physical hardware was removed with the intent of replacing it, and link A was created as a result of inserting replacement hardware into the system. In this case, we administratively simply wanted to replace link B's hardware. #1 is quite intuitive, but #2 is less so. It creates some ambiguity where a piece of software observes the rename operation, but cannot easily tell if the state associated with A should be preserved or not. For example, consider filtering rules associated with a layer-2 filter. Perhaps the following command would more intuitively reflect the intent: dladm replace-phys B A This would mean, replace the physical device of link B with that of link A. This would also implicitly destroy link A's configuration, as it's known to be a transient link. I realize that libdladm already distinguishes between these cases (it actually splits case #2 into two subcases that need to be handled differently, but I view these as the same), so this would be more of a usability improvement rather than code cleanup. In terms of code, the libdladm functions that handle this could go from being called i_dladm_rename_link_c1(), i_dladm_rename_link_c2(), and i_dladm_rename_link_c3(), to something like i_dladm_rename_link() and i_dladm_replace_phys(). Does anyone have thoughts along these lines? -Seb _______________________________________________ networking-discuss mailing list [email protected]
