Sebastien Roy wrote: > Dan Groves wrote: >> >>>> 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: > > another option is to force the mapping of types that this interface > provides to those in smf to be 1-1. the api consumer would then be > required to do range checking specific to the property being handled, > and cast to a more specific type if necessary. how feasible would that be? >
We could. I think it limits the API and imposes an extra burden on the API user. On the other hand, the SMF repository for linkmgmtd is cleaner. And as stated in my other e-mails, someone who feels too constrained by the existing types could always convert to/from a string when they use the dladm_[get|set]_conf_field functions. Going to and from a 64 bit integer shouldn't be all that hard, as long as it is documented that a 64 bit integer is what we use. That's important, because if the user does something like this: uint16_t vlanid = 123; dladm_set_conf_field(conf, "vlanid", (void*)&vlanid, DLADM_TYPE_INT); The correct data won't be stored because when we convert to a string we'll assume an 8 byte integer, instead of the two byte integer the user declared. While I've rambled a bit, I think this idea could work. thanks for the comments, Dan
