Sebastien Roy wrote: > 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. >
I think we could do this, maybe we could mention it in linkmgmtd's man page? > you still need to solve your data-type problem if you go with #1. > right. >> >> 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? > There were two reasons why I decided to have the library do the conversion into strings: a) Why should the library user care how the data is eventually stored? b) it makes the library easier to use. I remember in the design document discussions we back on forth on how to get and set data via the dladm_[get|set]_conf_field functions. I agree that this method is not as extensible; however, does the increased usability of the API offset the lack of extensibility? Remember that the user can always convert the data to a string and use the string type if there isn't an existing type. >> 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. > Right, I wouldn't expect that SMF would provide all possible types. >> 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. > I don't see how this proposal prevents someone from doing that. >> 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. > Right. > also, how does #2 address the possible data corruption during renaming > problem you originally described? > It does not.
