On Mon, May 21, 2007 at 08:01:11PM -0400, Dan Groves wrote:
> Hi,
>
> Renee Danson wrote:
> >Hi Darren,
> >
> >Thanks for the comments.
> >
> >On Fri, May 18, 2007 at 10:43:19AM +0100, Darren Kenny wrote:
> >>Hi Renee,
> >>
> >>I think that this function signature for prop_get/set could be prone to
> >>programming errors due to no suitable type checking, could we not have a
> >>struct/union combo that brings these together, along the lines of:
> >>
> >> typedef struct {
> >> nwam_ncu_datatype_t datatype;
> >> union {
> >> char *v_str; /* NWAM_STRING_TYPE */
> >> uint32 v_uint32; /* NWAM_UINT32_TYPE */
> >> uint64 v_uint64; /* NWAM_UINT64_TYPE */
> >> ipaddr_t v_ipv4addr; /* NWAM_V4_ADDR_TYPE */
> >> in6_addrt v_ipv6addr; /* NWAM_V6_ADDR_TYPE */
> >> } value;
> >> } nwam_ncu_data_t;
> >>
> >> int nwam_ncu_prop_get(nwam_ncu_handle_t, nwam_ncu_proptype_t,
> >> nwam_ncu_data_t *);
> >> int nwam_ncu_prop_set(nwam_ncu_handle_t, nwam_ncu_proptype_t,
> >> nwam_ncu_data_t);
> >>
> >>This should, in theory, reduce the risk of error, and the allocation of
> >>the
> >>string will be owned by the get function, what do people think?
> >
> >Not a bad idea; but I was trying to be consistent with the model proposed
> >by the clearview UV team in their link property management interface
> >(project
> >page is http://www.opensolaris.org/os/project/clearview/uv/; there's a link
> >there to the "Link management API design"). We'll be overlapping with them
> >quite a lot, so it made sense to try and be consistent with what they're
> >doing.
> >
>
> I wrote the link property management document.
>
> One of the goals of the get/set functions in the link property
> management document was to hide how the data is stored. We didn't want
> to have the API user convert their data to strings every time they
> wanted to set a link property via the API, or to convert data from a
> string every time they get a link property via the API. I received a
> suggestion to look at the kstats library, and that's what I used as a
> basis for what I wrote up. It never occurred to me to try a
> struct/union combination.
>
> I think Darren's suggestion would be better than what I have. Granted,
> I haven't spent much time thinking about it yet. However, I don't know
> if we'd have enough time to switch over to it, given how far along we
> are with Clearview work, and that would mean more work for Renee if NWAM
> will try to stay consistent with the Clearview model. I'll CC
> clearview-discuss to see if anyone there has an opinion.
Thanks for the reply, Dan. I was concerned that you were too far along
for such changes, but if you can work it in, I agree that this approach
is worth considering.
-renee
