Hi, I ran into a slight problem while writing the code to read link data from SMF.
We defined several data types for use in setting fields in the datalink configuration structure. These are meant to be used as an argument for the dladm_set_conf_field function, and as a return for dladm_get_conf_field to indicate the type of data we're returning (assuming the caller is interested). SMF also has data types, and these are used to convert data to however the data is stored in the SMF respository. The problem is that there is not a one to one mapping between the data types we defined for link configuration data, and the data types defined by SMF. When linkmgmtd starts up and reads in link configuration data from SMF, how does it know what the proper data type is for the data? Converting to SMF's types is easy, it's converting back that's the hard part. There cannot be a one to one mapping between the two groups of data types. For example, SMF's only integer data type is a 64 bit type, but for link configuration we have several different integer data types. I see a few solutions to this. 1. Return the SMF type. I.e. even if the user wrote out a 16 bit integer, we'd return a 64 bit integer. I don't think this is a good idea at all. 2. For every property, add an extra property with a slightly different name whose value indicates the data type. For example, say someone wants to save a VLAN ID via the dladm_set_conf_field. They'd probably set it as a 16 bit integer. With this solution, when we wrote this configuration to SMF, we'd write a property called "vid" with the value the user passed into dladm_set_conf_field, and then another property, say "vid%" with the value corresponding to DLADM_DATATYPE_UINT16. When we need to read in the data from SMF, we'd read the "vid%" property first, get the type, then read the "vid" property from SMF as a string, and then use the type information to convert to what the user originally recorded. Cons: This solution places a limit on what API users can name link configuration fields. Pros: Very easy to implement. 3. We could change the current proposed SMF layout to include an extra level in the hierarchy. Unfortunately, SMF does not allow property groups inside property groups. So, instead of having only one instance (the default instance), we'd have an instance for each link. Then, we'd have one property group for each link property. Then each property group would have two properties, one for the value and another for the type. Cons: More difficult to implement. Pros: Doesn't limit how an API user names any fields. It also appears closer to what NWAM proposes. 4. Include a table in linkmgmtd that maps each possible field to both an SMF data type and one of the proposed DLADM_DATATYPE_* types. While this is easy, it makes adding new fields difficult and adds some type checking which is something I wanted to move away from. I like 3, Cathy leans towards 2. I don't believe we should try either 1 or 4. Anyone have any thoughts on the matter? thanks, Dan
