Hi, While implementing the persistent storage of link information/attributes for Project Clearview, I had a few ideas/thoughts.
The current proposal is to store link information in SMF property groups under a new service's (network/linkmgmtd) default instance. The property groups' name would be the link name, and the properties in the in property group would be that link's various link attributes/properties such as link ID, class, etc.. Here are my two thoughts about changing it, and I'd like to know if anyone else has any thoughts: 1 - Change the name of the property group to be something derived from the link ID. Pros: - Greatly simplifies the code for updating or renaming a link because the APIs rely on link IDs. - Fixes a potential problem with the rename case. Others have commented that renaming a link is very slow if I name the property group by the link name. That's one problem, but there is another, more serious problem. In order to rename a link, I would have to delete the old link's property group from SMF, and then create a new one under the new name. What if the link management daemon (which is making the changes to SMF) goes away in between the two steps? I.e. it crashes, the system reboots, or the administrator restarts the link management daemon. The administrator has lost information. One question for the SMF folks: Are there plans to add functionality to libscf so that someone can use libscf to rename an instance or a property group? You might say what happens if you implement this change and there is a crash in the middle of the rename operation? In this case, there is no loss of information because nothing is deleted, we only change the value of one property. Since this happens via the libscf scf_transaction_* functions, it is guaranteed to be atomic and the operation will not happen if it is interrupted in the middle. (If I?m wrong about that, please correct me). Cons: - We're exposing something private, the link ID. However, one can counter that by stating the link ID was exposed anyway as an administrator can see it by using svcprop to view all the properties and property groups for a service. Also, the administrator should not use the smf command line tools to modify or view the link information, but should only use dladm. However, in the real world of system administration, that would be wishful thinking (i.e. someone might need to use the smf tools for troubleshooting or recovery). 2 - Move the link information up a step in the SMF hierarchy, i.e. represent links in SMF as service instances instead of property groups. (The name of the instance would either be the link name or something derived from the link ID based on the response to 1) This change was motivated by implementing code for getting and setting link attributes in SMF. Cathy made a comment on the API design that the dladm_[get|set]_conf_field functions should not require the API user to convert data to or from strings. The library handles the conversion. I discovered there wasn't a one to one mapping between SMF types and the types I proposed using to store data. The set operation is easy, but the get is not. Consider the case of a VLAN id stored as a 16 bit integer, easy enough to convert to SMF?s 64 bit integer type on a write, but how do I know how to convert back on the read? So I would need to store extra type information in SMF. As far as I can tell, the best way to do this is to move everything up one level in the hierarchy: links are instances link attributes are property groups each property group has two values, one is the link attribute's type and the other is the link attribute's value If someone has a better idea, I'd be glad to hear it. Pros: - A much better solution than the alternative: store the type information as another SMF property with a different name. We might have conflicts in the future between the name used to identify a link attribute's type and an actual link attribute. Cons: - I can't think of any. Any thoughts? thanks, Dan
