> You're talking about in general for Clearview, and not specifically with
> regard to link properties, right?
>
Right.
> > Let's see the example of "up" an aggregation in liblaadm:
> >
> > laadm_up(uint32_t key, const char *root, laadm_diag_t *diag)
> > {
> > ...
> > if (i_laadm_walk_db(i_laadm_up, &up, root, diag) < 0) {
> > ...
> > }
> >
> > Note that i_laadm_walk_db will be replaced by dladm_datalink_xxx calls
> which
> > belong to libdladm. We could generalize this to have liblaadm to register
> a
> > up() function pointer. There are lots of places like this in liblaadm
> > though. Do we really want to rewrite and redesign the whole library?
>
> I'm confused why this would need to be redesigned, unless there are now
> cases where liblaadm needs to call back into libdladm. The discussion
> thus far has focused on the link property code, so I'm a little lost here.
>
Like I mentioned in a mail to Eric, that there is always the chance that
other libraries need to call libdladm functions, if libdladm is where we put
all general functions. I gave the example of the datalink configuration API,
which we are currently making as a part of libdladm. The above example shows
why we need liblaadm to call datalink configuration APIs.
Thanks
- Cathy
