Dan Groves wrote: > 1 - Change the name of the property group to be something derived from > the link ID. > > Pros: > ... > > 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).
all of the properties of the linkmgmntd service are meant to be private, since the public interface to access the configuration information is dladm. i think that if it can be made clear that the service and its properties (including the name of the property groups) are private interfaces, then i have no issues with this approach. you still need to solve your data-type problem if you go with #1. > > 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. i'm not sure i understand why that should be the case. the format of the data being stored could be such that it can't possibly be represented by one of smf's basic types, so the caller has to be expected to do conversion to and from strings in that case. why is this bad? > 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. that's not a surprise. we store all kinds of data in smf that can't be represented in a binary form using their native types; ip addresses and mac addresses being two good example. it is a given that smf cannot possibly have a type for everything that one might want to store as a property. > 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. an alternative approach is to store everything as a string and have the consumers of the api do the conversion. i think this is also more extensible for future data that consumers of the api may want to store for which smf has no type. > 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. here's one: on a system with hundreds of links (such as a VPN access point with tons of tunnels), this would clutter svcs output. also, how does #2 address the possible data corruption during renaming problem you originally described? overall, #2 seems very hack-ish to me. -seb
